[Bobboau]

it means we'll have bigger tables, but it won't break peoples computers that can't handel it

[aldo_14]

So, (I think) a registry entry dictates the maximum allowed tbl size for a Pc so it doesn't overruse RAM?  That's pretty cool.

[Sandwich]

Originally posted by aldo_14
So, (I think) a registry entry dictates the maximum allowed tbl size for a Pc so it doesn't overruse RAM?  That's pretty cool.

Ahh, ok - as long as it's not something as ridiculous as storing the table data itself in the registry...

[Nuke]

i hope we are not contaminating the game with microsoft, thatwould be bad. i have added maby a dozen or so ships and even more weapons to the tables with no problems. table limit expansion is over rated.

i like the binary table idea though, but someone would have to make a gui. it would be nice if it was built into fred, along with the pof tools, ani tools, and a vp compiler. fred would save vp files and could be used to assemble mods directly. take it even farther than that and you could use fred's 3d interface as a basis for a pof modeller. that would make fred all you really need to make a full mod.

[r0nin]

Errr, as the programmer (sort of) for the RT mod, I've been looking over the animation question for a while now.  Three main issues exist:

One, the specific method of storing the different frames are undefined.  Storing various frames in the model itself might require any or all of the following: changing the pof file format, changing the way the code reads the model file, and/or changing the way FS2 actually renders the model.  This is a problem because, quite frankly, I don't know how to do any of the above!  At least, I would have to develop the new routines by trial-and-error, and that takes LOTS of time.

Two, using methods already in FS2 might cause severe performance hits... and there's no way to tell without trying.  Two examples of methods that mimic routines already in FS2 would be recoding the LOD function to allow more LODs and cycling through them for the animation or creating a pof for each frame and switching pofs after rendering with a timestamp.  The second will almost certainly hog memory.  As for the former, some code would have to be implemented to tell FS2 which ships use LOD as normal and which have it reserved for animations.  Plus, the effect on the performance of the much larger pofs is an additional unknown.

Three, the engine instelf was not really designed for animation, so there are a number of completely unexpected bugs that could crop up (I'm betting on lot's of them).

So, the whole thing isn't as simple as dropping in a new model and changing a few lines of code.  There are probably coders here on the SCP who could work this out in a relatively short time, but I ain't one of 'em...

[Nuke]

we dont really need some fancy vertex by vertex animation, a simplie method of subobject animation, there keyframes are used at various points in time to indicate subobjet rotation, translation and possibly scale. for the idea of gatling guns, the fire comand calls a function that begins to increase the rotational velocity of the barrels, which in turn calls the function the fire the weapon. you could simply have 4 keframes every where the barrels rotate 90 degrees. the time between yframes is then scaled as the barrels spin up or down. the end resuld is a fully syncrhonized gatling gun effect. the same stuff could be applied to docking bay doors, which will translate (move) between two vectors when a ship is spawned inside the bay. descent 2 is a good example of what im talking about, robots seem animated but its just relitave subobject movements.

anything beyond that (rippeling surfaces, shadow vessels) could use vertex shaders, which i belive are in direct-x 8.1. you see the alive effect on some surfaces in certain quake 3 maps.

[Nico]

vertex by vert-ex animation? whoa, a new one

animating surfaces does not require vertex shading, an ani will do fine. rippeling surface ( I mean real, volumetric ), is out of our range.
Descent2 robots are animated, they use keyframes. relative movements of subobjects is just one way.

[Sandwich]

Originally posted by r0nin
Errr, as the programmer (sort of) for the RT mod, I've been looking over the animation question for a while now.  Three main issues exist:

One, the specific method of storing the different frames are undefined.  Storing various frames in the model itself might require any or all of the following: changing the pof file format, changing the way the code reads the model file, and/or changing the way FS2 actually renders the model.  This is a problem because, quite frankly, I don't know how to do any of the above!  At least, I would have to develop the new routines by trial-and-error, and that takes LOTS of time.

Two, using methods already in FS2 might cause severe performance hits... and there's no way to tell without trying.  Two examples of methods that mimic routines already in FS2 would be recoding the LOD function to allow more LODs and cycling through them for the animation or creating a pof for each frame and switching pofs after rendering with a timestamp.  The second will almost certainly hog memory.  As for the former, some code would have to be implemented to tell FS2 which ships use LOD as normal and which have it reserved for animations.  Plus, the effect on the performance of the much larger pofs is an additional unknown.

Three, the engine instelf was not really designed for animation, so there are a number of completely unexpected bugs that could crop up (I'm betting on lot's of them).

So, the whole thing isn't as simple as dropping in a new model and changing a few lines of code.  There are probably coders here on the SCP who could work this out in a relatively short time, but I ain't one of 'em...

Or you could simply copy the manner that was used in Total Annihilation. Versatile, simple, and powerful.

[Nuke]

you forget that there is a difference between pixel shaders and vertex shaders. vertex shaders create a 3d effect by distorting the vertices that make up the model in a pre scripted manner. a pixel shader creates effects by distorting the pixels in a texture, also in a pre scripted manner. as far as i know shaders have far less overhead than preanimated textures, because your video and/or system memory must store many images, while shaders use only a couple. they require a tad more processing though, but most modern video cards can do this easily. personally i think shaders look better than any animation can.

vertex by vertex animation means that your model has frames. each frame is virtually a different model for each frame in the animation. some games intrepolate between frames by calculating new frames to fill in the gaps. skelatal systems are used in fps games, it has potential in a gundam or mechwarrior type game. for spaceships i see no use for it. its probibly beyond the scope of the programmers we got working on freespace. it could be done though, if people want to spend the time on it.

seriously though, descent 2's animation system would work like a charm. its fast and it would be easy for modders to implement (for the programmers it will be a little more trickey). it would of course need to be more sophisticated than descent 2's.

[r0nin]

Originally posted by Sandwich


Or you could simply copy the manner that was used in Total Annihilation. Versatile, simple, and powerful.

Which is?  Seriously, I don't know how they did it, nor do I have the source code, and I would be seriously interested.  Let me know where to find it!

[Nico]

Originally posted by Nuke
you forget that there is a difference between pixel shaders and vertex shaders. vertex shaders create a 3d effect by distorting the vertices that make up the model in a pre scripted manner. a pixel shader creates effects by distorting the pixels in a texture, also in a pre scripted manner. as far as i know shaders have far less overhead than preanimated textures, because your video and/or system memory must store many images, while shaders use only a couple. they require a tad more processing though, but most modern video cards can do this easily. personally i think shaders look better than any animation can.

vertex by vertex animation means that your model has frames. each frame is virtually a different model for each frame in the animation. some games intrepolate between frames by calculating new frames to fill in the gaps. skelatal systems are used in fps games, it has potential in a gundam or mechwarrior type game. for spaceships i see no use for it. its probibly beyond the scope of the programmers we got working on freespace. it could be done though, if people want to spend the time on it.

seriously though, descent 2's animation system would work like a charm. its fast and it would be easy for modders to implement (for the programmers it will be a little more trickey). it would of course need to be more sophisticated than descent 2's.

1 I didn't mix up, don't worry the pb is that vertex shader requires the creation of an awful lot of polys, it's not just a visula effect, and the imapct on performances IS important.
vertex by vertex aanimation as you call it, is just a simple key animation. the name fooled me, sorry.
And yeah, I agree Descent2 way is the best ( even more when you think the freespace engine is a derivative from the descent engine )

[Sandwich]

Originally posted by r0nin


Which is?  Seriously, I don't know how they did it, nor do I have the source code, and I would be seriously interested.  Let me know where to find it!

http://www.planetannihilation.com/tamec/helpdesk/TA/ta_design_guide/tadesign/unitdsgn.htm

Scroll down to the section called "Animate Your Unit", read it, and follow the BOS link. Hope that helps!