[Kazan]

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.
Alliance Productions

[Joey_21]

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 project.
IRC: /server twisted.ma.us.DAL.net /join #Deneb
Visit The Deneb System.
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

[Kazan]

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).]

[Eth]

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).

[Kazan]

 

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.
Alliance Productions

[Eth]

 

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).]

[Martinus]

 

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  

[Kazan]

 

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..

[Bobboau]

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

[Kazan]

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.
Alliance Productions

[Bobboau]

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

[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.

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

[Nico]

 

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?   Already happened to me, the normals were flipped for some reason when converted.

[Kazan]

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.
Alliance Productions

[Taristin]

Me hopes...  

[Kazan]

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.
Alliance Productions

[Taristin]

Cool. I hope it is real easy. Cause I am real dumb with new software.  

[Kazan]

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.
Alliance Productions

[Taristin]

Kudos! Now thats what I'm talking about!

[This message has been edited by Raa Tor'h (edited 07-22-2001).]

[Kazan]

get your ***  on ICQ