Hard Light Productions Forums
Off-Topic Discussion => General Discussion => Topic started by: Kazan on July 20, 2001, 08:24:00 pm
-
I'm getting ready to go through and start cleaning the GUI and optimizing some code I flagged a while ago for optimization.
Get your bug reports in now
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. (//"http://freespace.volitionwatch.com/babylon")
Alliance Productions (//"http://alliance.sourceforge.net")
-
When "importing" data, it doesn't get the turret info and the information for the turret subobjects. Instead, it creates new info.
------------------
Creator of the Table Edit ("http://denebsystem0.tripod.com/tbledt.html") project.
IRC: /server twisted.ma.us.DAL.net /join #Deneb ("http://denebsystem0.tripod.com/chat.html")
Visit The Deneb System ("http://denebsystem0.tripod.com/").
Balance?! Don't you talk to me about balance when you've seen all the Sathanases the Shivans have!! - Joey_21
Checkout the System Madness II campaign ("http://denebsystem0.tripod.com/chi2orionis.html")
-
it's not suppose to import turret data - because of AutoTurret
any data that I had generated during conversion will not be imported
[This message has been edited by Kazan (edited 07-20-2001).]
-
Most are not new, but so they are all in one place (most are features, only a couple of issues)...
1) Add the ability to import the lights in the HDR chunk from another model (as well as mass data, etc.)
2) Allow the import of _selective_ chunks from another model (for example, only import the FUEL chunk)
3) Delete unused vertices (use a post process scan)
4) Take a serious look at the shield problem
5) Add a "default import" and "default export" path to the settable options.
6) Related to #1... create an "automatic light generator" that creates the lights in the HDR chunk, Type 2 lights where engine glows are and Type 1 lights for gun and missle points.
7) Do a check on all the polys while parsing to see if they are flat. Report _warnings_ for all non-flat polys. (use simple plane equations, derive the normal of the plane using 3 points of the poly, check if the 4th through nth points reside on the plane surface, allowing some fractional deviation for the inaccuracies of the floating point math).
-
Originally posted by Eth:
1) Add the ability to import the lights in the HDR chunk from another model (as well as mass data, etc.)
already implemented
Originally posted by Eth:
2) Allow the import of _selective_ chunks from another model (for example, only import the FUEL chunk)
This i can do
Originally posted by Eth:
3) Delete unused vertices (use a post process scan)
Do I have to explain to you for a 15th time why i cannot do this? [well, will not, because it makes it more likely to corrupt the data, makes it even more breakable, etc]
Originally posted by Eth:
4) Take a serious look at the shield problem
I did, i found no problem, remember
Originally posted by Eth:
5) Add a "default import" and "default export" path to the settable options.
that would be redundant
Originally posted by Eth:
6) Related to #1... create an "automatic light generator" that creates the lights in the HDR chunk, Type 2 lights where engine glows are and Type 1 lights for gun and missle points.
Well I've seen the engine lights in action, but i've never seen type 1. There is a data editor for this, i find this data useless as of right now, so use the direct editor - no autogen
Originally posted by Eth:
7) Do a check on all the polys while parsing to see if they are flat. Report _warnings_ for all non-flat polys. (use simple plane equations, derive the normal of the plane using 3 points of the poly, check if the 4th through nth points reside on the plane surface, allowing some fractional deviation for the inaccuracies of the floating point math).
You have any IDEA what type of performance hit this would be? anyways a good modeler should know better
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. ("http://freespace.volitionwatch.com/babylon")
Alliance Productions ("http://alliance.sourceforge.net")
-
Eth:
4) Take a serious look at the shield problem
Kazan
I did, i found no problem, remember
No, not based on your email. You couldn't _explain_ the cause of it. If you had looked at the test model I sent you, the problem was blatantly obvious. I would wager a pound of space crack you _never_ loaded those test models up in FS2 and fired at them with guns.
In regards to #5:
Kazan
that would be redundant
How so? For example, I keep COB, OBJ, etc. files of a model in a seperate directory. I usually want the POFs to go to FS2\data\model directory. I doubt most people keep their non-POF model files in the FS2\data\model directory.
In regards to #7:
Kazan
You have any IDEA what type of performance hit this would be? anyways a good modeler should know better
Let's just say for the sake of discussion that it DOUBLED the amount of time it takes... so it goes from 2 or 3 seconds to 4 or 5 seconds... so? As far as "knowing better"... people make mistakes, errors creep in sometimes. Your call... just having seen the number of posts in various places about problems that were caused by an inadvertent bent poly or two I thought it might be helpful.
[This message has been edited by Eth (edited 07-21-2001).]
-
Originally posted by Eth:
Do a check on all the polys while parsing to see if they are flat. Report _warnings_ for all non-flat polys. (use simple plane equations, derive the normal of the plane using 3 points of the poly, check if the 4th through nth points reside on the plane surface, allowing some fractional deviation for the inaccuracies of the floating point math).
I agree with Eth, performance is not really a priority, I know you like to have clean, fast programs but in this case it isn't really a consideration. It could take a minute to check the model with your program and it would still save time over the "manual" method. Tracking down that kind of error, especially if there is more than one instance of the error can take a considerable amount of time to do.
I personally think you should consider it but it's your program so I'm OK with anything you should release, it's all good (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif)
-
Originally posted by Eth:
How so? For example, I keep COB, OBJ, etc. files of a model in a seperate directory. I usually want the POFs to go to FS2\data\model directory. I
doubt most people keep their non-POF model files in the FS2\data\model directory.
because in options there is this thing called
"Default Model Directory"
types: COB/SCN, POF, i haven't check if i've written support for plugin types yet..
-
there does seem to be a bug in the sheild code, it took me nearly three days of converting with varius tools and hexediting together stiches of code to get a thing for BWO to work, and the were other ships I've made that have all had unexplained sheild related problems.
and the vert remover and flatness checker would be very nice options particularly the flatness checker.
and the light aoutogen would be easy just make it so it makes lights with the TGUN FUEL and GPNT aoutogen. I havn't seen the engine lights but I have seen the gun lights so it seems that diferen't systems have diferen't rendering abilitys.
------------------
Bobboau, bringing you products that work.............. in theory
-
grr... where is this ****ing bug in the shield code.. i've never seen it and i've done shields with PCS
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. ("http://freespace.volitionwatch.com/babylon")
Alliance Productions ("http://alliance.sourceforge.net")
-
I would also like to see some documentation on the aoutogen including nameing conventions and examples, or you could just make it so that POF2COBing would have the stuf in place.
and do you said you didn't know how light sizes are stored, how about amplatude, or any other data that could be used for extra data.
------------------
Bobboau, bringing you products that work.............. in theory
-
well the bug that caused me the big problems caused crashes when I fired at it, or the sheilds wouldn't work at all, or they would go through and hit the other side. This bug seemed most pronounced on a model that had an unusualy wide sheild mesh, it seems that the bounding box was somewhat involved with this becase when I made a larger box it finaly started to work (wich reminds me could there be a way to set a new bounding box, like a cube named "bounding box") but it still crashed for some while eventualy I managed to hex in a sheild made from an antiquated converter and with the poly data from PCS and a bit of screwing around I got it to work. I figured it was just my wonderfull luck that I was having such a problem but sence more people seem to be having problems it seems it was the code.
------------------
Bobboau, bringing you products that work.............. in theory
-
Originally posted by Bobboau:
well the bug that caused me the big problems caused crashes when I fired at it, or the sheilds wouldn't work at all, or they would go through and hit the other side. This bug seemed most pronounced on a model that had an unusualy wide sheild mesh, it seems that the bounding box was somewhat involved with this becase when I made a larger box it finaly started to work (wich reminds me could there be a way to set a new bounding box, like a cube named "bounding box") but it still crashed for some while eventualy I managed to hex in a sheild made from an antiquated converter and with the poly data from PCS and a bit of screwing around I got it to work. I figured it was just my wonderfull luck that I was having such a problem but sence more people seem to be having problems it seems it was the code.
May I suggest you to check the normals of your shield? (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif) Already happened to me, the normals were flipped for some reason when converted.
-
i would have to agree with venom
Oh... POF Constructor Suite is getting a _MAJOR_ interface upgrade right now.. I think you'll like it
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. ("http://freespace.volitionwatch.com/babylon")
Alliance Productions ("http://alliance.sourceforge.net")
-
Me hopes... (http://dynamic.gamespy.com/~freespace/ubb/noncgi/wink.gif)
-
you should be playing with the new interface by noon :d
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. ("http://freespace.volitionwatch.com/babylon")
Alliance Productions ("http://alliance.sourceforge.net")
-
Cool. I hope it is real easy. Cause I am real dumb with new software. (http://dynamic.gamespy.com/~freespace/ubb/noncgi/wink.gif)
-
why don't you go download it and find out
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. ("http://freespace.volitionwatch.com/babylon")
Alliance Productions ("http://alliance.sourceforge.net")
-
Kudos! Now thats what I'm talking about!
[This message has been edited by Raa Tor'h (edited 07-22-2001).]
-
get your *** on ICQ
-
oops, hehe
-
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 (http://dynamic.gamespy.com/~freespace/ubb/noncgi/wink.gif) Sorry about that (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif)
[This message has been edited by Eth (edited 07-22-2001).]
-
edit: pointless post
[This message has been edited by venom2506 (edited 07-22-2001).]
-
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
-
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
-
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
-
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 (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif)
-
Darkage was complaining about that too, to venom...
-
gimmie the freaking model.. i'll look again
-
Originally posted by Raa Tor'h:
Darkage was complaining about that too, to venom...
Maybe, I don't remember, which model?
-
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... (http://dynamic.gamespy.com/~freespace/ubb/noncgi/tongue.gif)
-
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! (http://dynamic.gamespy.com/~freespace/ubb/noncgi/biggrin.gif)
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 (http://dynamic.gamespy.com/~freespace/ubb/noncgi/wink.gif)
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.
-
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]
-
tell me if C->P C V 1.1.2 works eth
-
Your welcome (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif) [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 (http://dynamic.gamespy.com/~freespace/ubb/noncgi/biggrin.gif) (http://dynamic.gamespy.com/~freespace/ubb/noncgi/lol.gif)
-
don't make me explain why deleting unused verticies is unfeasable for the 20th time
-
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 (http://dynamic.gamespy.com/~freespace/ubb/noncgi/tongue.gif) (http://dynamic.gamespy.com/~freespace/ubb/noncgi/lol.gif)
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 (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif) IF the shield is imported however, the bounding box is not updated, and thus the shields do not work. Ooooops (http://dynamic.gamespy.com/~freespace/ubb/noncgi/wink.gif) 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" (http://dynamic.gamespy.com/~freespace/ubb/noncgi/tongue.gif) {ducks} <--- there should be a "ducks" there.
-
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
-
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
-
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" (http://dynamic.gamespy.com/~freespace/ubb/noncgi/tongue.gif) {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
-
you guys are going to love me.. i added a couple pointless graphics to the interface to take up unused space.. a couple of them look pretty damned nice
------------------
There are times in our lives when everything crystallizes and truths become evident, he has entered one of these times.
-----------------
FreeSpace 2: The Babylon Project Effects Nerd and Programmer. ("http://freespace.volitionwatch.com/babylon")
Alliance Productions ("http://alliance.sourceforge.net")
-
I have a nice buf to report: it doesn't save the docking points.
edit (http://dynamic.gamespy.com/~freespace/ubb/noncgi/tongue.gif)lus when I open an existing fs2 model (to check, coz maybe I messed up somewhere, I thought), the coordinates for the paths are completly wrong.
[This message has been edited by venom2506 (edited 07-30-2001).]
-
or they're completely right and you just don't understand the coordinate system
-
bugs ("http://dynamic.gamespy.com/~freespace/ubb/noncgi/Forum2/HTML/000535.html")
------------------
Bobboau, bringing you products that work.............. in theory
-
Originally posted by Kazan:
or they're completely right and you just don't understand the coordinate system
I know I'm stupid, but not to that point.
I compared with the ones show in FSMM2.
plus both paths shares EXACTLY the same coordinates in PCS. But maybe I don't know how to read, right?
-
Z axis + = front of ship
Z axis - = back of ship
X+ = right of ship
X- = left of ship
Y+ = top of ship
Y- = bottom of ship
radius = general 'area' to be in to have reached that point [i think.. never was fully explained]
-
Originally posted by Kazan:
Z axis + = front of ship
Z axis - = back of ship
X+ = right of ship
X- = left of ship
Y+ = top of ship
Y- = bottom of ship
radius = general 'area' to be in to have reached that point [i think.. never was fully explained]
I know that, thanx. So it means you should have a closer look at how PCS handles the paths (http://dynamic.gamespy.com/~freespace/ubb/noncgi/wink.gif)
oh, also, I noticed a pb with the engine glows. I resized them all on my model, but for some reason one of them was still bigger than the others. Saving again (without modifying anything) fixed it tho. Not really a big pb, but annoying anyway.
-
Thats essentially FRED2s coordinate system isnt it? regarding rotation of models and so on... if you get stuck you could practice in that (http://dynamic.gamespy.com/~freespace/ubb/noncgi/smile.gif)
------------------
| | ICQ:57179504 |
Co-Creator: Hard Light Productions ("http://www.3dap.com/hlp/")
Webmaster: Sounds of Thunder ("http://www.3dap.com/hlp/sot/")
-
it's the model coordinate system.. period
-
Originally posted by Kazan:
it's the model coordinate system.. period
which are wrong in PCS. Period(as you say).
-
umm, if the model coordinate system in PCS was wrong, it would be wrong in my engine code, if it was wrong in the engine code the model WOULDN'T WORK
-
save the model from fsmm2 then open it in PCS, FSMM2 screwed up some models.
------------------
Bobboau, bringing you products that work.............. in theory
-
Sorry that this bug report came so late.
I once tried to add guns to a GTF Apollo fighter in FreeSpace 1 and when the Apollo was hit by laser fire, it seemed to be pushed back a great deal. I checked the ships.tbl file and the Apollo didn't seem to have its mass changed at all.
What could be wrong?
------------------
I want a better title!!! (http://freespace.volitionwatch.com/excellence/Crazy.gif)
GTD Excellence ("http://freespace.volitionwatch.com/excellence") Webmaster
NeoHunter< [b][email protected][/b] >
Not to mention a FREDder! :)
-
POF CS shoundn't open FreeSpace 1 POFs - it'll return "POF Version Mismatch, are you sure this is a freespace 2 pof?"
-
Hmm....I'm not entirely sure. I'll have to wait till I get home and test it again.
By the way, great work combining POF editing tools with MODELVIEW. I also like the WYSIWYG interface. Easier for people like me to understand. Now I can make fighters with 10 guns and all. (http://dynamic.gamespy.com/~freespace/ubb/noncgi/biggrin.gif)
------------------
I want a better title!!! (http://freespace.volitionwatch.com/excellence/Crazy.gif)
GTD Excellence ("http://freespace.volitionwatch.com/excellence") Webmaster
NeoHunter< [b][email protected][/b] >
Not to mention a FREDder! :)
-
umm... that's Heiko's Cup of Tea - i don't program modelview