[Taristin]

oops, hehe

[Eth]

Kazan... look at the test model I sent you and you will see the problem.  If you deleted it I can email it to you again.

Regarding the directory options...there is a _single_ path currently used for both the input and output paths.  I was _requesting_ a _seperate_ path for each.

Venom... nope, it isn't a problem with the shield normals.  The _exact_ same COB files and shields work _completely_ when the conversion is done with Cob2FS2.  This is with several different real models as well as an extremely simple little test model I generated so that Kaz would have something he could look at easily (it consisted of a total of 18 polys plus 12 polys for thrusters).  I sent the COB, a POF made with Cob2FS2 that works, and one made with PCS that didn't.

Edit: Venom, flipped normals _might_ have been one of Bobboau's problems (in reading the part of his post about hitting the other side of the shield).  I should have said, in my case it isn't a flipped poly normal problem    Sorry about that  


[This message has been edited by Eth (edited 07-22-2001).]

[Nico]

edit: pointless post

[This message has been edited by venom2506 (edited 07-22-2001).]

[Bobboau]

I fliped the polys several times becase I couldn't tell wich way they were faceing they still did it, and they wouldn't always shoot through some times they would hit then the next shot would go through then the next shot would hit the far side sometimes they would hit both the front and back (I wasn't shooting in the same place), but they usualy just crashed.

------------------
Bobboau, bringing you products that work.............. in theory

[Bobboau]

and I do like the new interface, it would be nice if it wasn't as tall

------------------
Bobboau, bringing you products that work.............. in theory

[Kazan]

if the shield mesh is too close to the ship it's always shot-through.. i noticed that with cob2fs2 way back in the day

[IceFire]

I know of the particular model that Bobboau is refering to, because I fought with it (not that I really know what im doing) several times before giving my bug report to Bobboau, namely because I don't want to just tell him "it doesn't work".

It was very strange in that some of my shots would pass through and others not.  It might have been a bit like the flythrough problems on some ships back in COB2POF where some polys you could fly through and others you could not.

Just my brief comments  

[Taristin]

Darkage was complaining about that too, to venom...

[Kazan]

gimmie the freaking model.. i'll look again

[Nico]

 

Originally posted by Raa Tor'h:
Darkage was complaining about that too, to venom...

Maybe, I don't remember, which model?

[Taristin]

Err... I don't remember... but I remember someone talking about the sheilds not working... Sorry, it was not you, venom, it was Darkage and Woo...  

[Eth]

Kaz, I sent you those models again along with some other stuff... but it appears I found the problem.  At least it solves the problems on 3 different models I tested the "fix" on in which the shields had NOT worked when using PCS to generate the POFs.

Something Bobboau posted about his shield problems was the missing piece.

As I had told you before, the shields only worked on the back portion of the various models I tried PCS on, in the area of the thrusters, no where else.  I got to thinking, what is so special about that area of the models?  I went back and looked at the POF files again with PofDView and remembered what Bobboau said about diddling with the Bounding Box.  I got to looking at the bounding box in the HDR chunk versus the model itself and the shields.  I noticed that the bounding box was larger than the model by a fair degree in the direction of the thrusters (-z), while it was the same as the model size in all other directions (which puts it inside the shield's confines.  It turns out your bounding box calcuation includes the thrusters themselves but not the shield.  On all of my test models the thrusters extend a fair way past the confines of the shields.

So, I went and pulled up the test models with a hex editor and changed the values of the bounding box in the HDR chunk so that they encompassed the shield as well as the model (plus a 1 meter margin) and changed the radius to match the new bounding box value.  Voila, the shields work now!  

So, it appears that the bounding box and radius values in the HDR chunk should be for the entire object, including the shields. (whether or not the thrusters should be included is another matter, can't think of any reason why they should be included, but it probably doesn't hurt to) In going back and looking at the difference between the Cob2FS2 generated files and the PCS generated files, there is indeed a significant difference in the bounding box values and the max radius values (you can see this in the files I sent you).

Side note, you were right, the shield problem  wasn't due to the BSP structure  

Note: this has nothing to do with the crashing problem Bobboau spoke of, as I haven't run across that problem.  This  deals only with the shields properly working.

[Kazan]

i figured so much


thanks eth [update your POF CS Version! the current compiler is v1.1.1 and model you sent me was v1.0.5INTERAL for crissakes]

[Kazan]

tell me if C->P C V 1.1.2 works eth

[Eth]

Your welcome   [hey, what can I say, when you gave up on looking at the shield problem, I kind of gave up trying to use PCS for model conversion]

Maybe now I can coerce you into adding those other two features now      

[Kazan]

don't make me explain why deleting unused verticies is unfeasable for the 20th time

[Eth]

 

Originally posted by Kazan:
tell me if C->P C V 1.1.2 works eth

Ok...

if C->P C V 1.1.2 works

then Kaz blows a fuse


Anything else you want me to tell you    


Seriously... it works to an extent.  IF the shield is part of the original COB file, the shields now properly work with the corrected bounding box    IF the shield is imported however, the bounding box is not updated, and thus the shields do not work. Ooooops    Looks like you really need to add some "update HDR data if shield imported" logic.

I also noticed in the latest version an apparent bug that I haven't seen before... the textures retain their filename extensions (i.e. they are called texture_name.bmp in the POF file rather than just plain texture_name).  ????

Originally posted by Kazan:
don't make me explain why deleting unused verticies is unfeasable for the 20th time
[/b]

Darn it... I had a {duck} in between the grin and lol smilies but for some reason it disappeared... grrrrrr.  I knew that would be your reply to one of the requested features.  I know why you said it wasn't feasible... but in my view, just like the shield problem, that is another way of saying "I haven't figured it out"   {ducks} <--- there should be a "ducks" there.

[Kazan]

 

Originally posted by Eth:

I also noticed in the latest version an apparent bug that I haven't seen before... the textures retain their filename extensions (i.e. they are called texture_name.bmp in the POF file rather than just plain texture_name).  ????

what? show me

[Kazan]

PCS 0.98.1b [i just sent you it] should fix the import problem.. i didn't see any trace or any logical reason for this texture name bug

[Kazan]

 

Originally posted by Eth:

Darn it... I had a {duck} in between the grin and lol smilies but for some reason it disappeared... grrrrrr.  I knew that would be your reply to one of the requested features.  I know why you said it wasn't feasible... but in my view, just like the shield problem, that is another way of saying "I haven't figured it out"   {ducks} <--- there should be a "ducks" there.

oh yeah, i know exactly[/i] what needs done... doesn't meant it's feasable, safe, or really matters - D3D and Glide cull the unused vert.. it's just 12 bytes of extra data.. wow