[quote=“t_larkworthy,post:29,topic:32838”]
Cool, but don’t lose sight of the objective, which is ease of use - a big problem is assets: If we encourage devs to use textured 3DS models we’ll get massive asset issues: ‘I’ve done a 2000 poly fully textured deathstar!’ means: ‘I’ve just raised the load time by 10 mins & made the renderer drop to 1 fps’. In software mode JPCT can’t really go over 2000 textured polys total. Plus we’d need to manage the assets (versioning, server space &c). This is why I favour a procedural approach (eg, that JPCT test applet had no art assets).
A 2000 poly/frame world is very different from a 40000 poly/frame world - the physics and renderer need to be tight.
OK. loud and clear. The binding for JPCT I will add to JOODE will not be the same as the one we use in this project anyway.
How will people make art? They will use blender -> 3DS just for designing the meshes?
Tom
Good question! What format’s best for you on the physics side? How can we keep the overall poly count down to playable levels?
Well its fairly standard practice to have a lower polygon count for the collision mesh to help prevent the sporadic collision checks being a bottle neck. I have no idea whether they will be or not. I suspect collision detection will not be the bottleneck but rendering. If collision detection is an issue we can prevent AI ships from colliding with anything other than missiles with springs or something. Then really the only true collider becomes the player, and the missiles can be simplified to a point or something (i.e. the physics can be tuned pretty easily).
I think our major time saver will be rendering far away ships as really low dimensional poly’s eventually simplifying them to be a single triangle of roughly the right color when miles away from the camera.
So how the question is whether the artists have to be responsible for producing different resolution polys or whether we try to do that automatically. (option 1 is hard on the artists, option 2 is hard on the coders)
[quote]What format’s best for you on the physics side?
[/quote]
Oh its doesn’t really matter. As long as I can get at the mesh verteces to build trimeshes it does not really make much odds.
I think making the artists job the easiest is the best direction. I dunno how people will use procedural texture generation and be able to model in a gfx program at the same time (unless we have a blender plugin or something)
Tom
Cool, rendering is definitely the biggest problem!
[quote]I think our major time saver will be rendering far away ships as really low dimensional poly’s eventually simplifying them to be a single triangle of roughly the right color when miles away from the camera.
So how the question is whether the artists have to be responsible for producing different resolution polys or whether we try to do that automatically. (option 1 is hard on the artists, option 2 is hard on the coders)
[/quote]
No such a problem (hopefully), I’d already thought of some form of imposting (ie pre-rendered images) for more distant objects, so I guess that a single low-poly model will do from the artists. I wonder about ships breaking up though (especially large ones) - we’ll need some way of splitting the mesh when a ship explodes… I looked into voxels but no way we’ve got the CPU beef to do it!
[quote]I think making the artists job the easiest is the best direction. I dunno how people will use procedural texture generation and be able to model in a gfx program at the same time (unless we have a blender plugin or something)
[/quote]
I’ve a feeling you’re right, but we’ll have to heavily stress the low poly/small texture requirements!
all the models for the RTS are going to be very low poly (as high polies are not needed in any way). Also I will be making calapsed versions of the polies, (these probably wont be UV mapped as there going to be so small, so texturing will be disabled and they will be rendered in the dominant color.
A primary mesh will have a poly count like the model update I posted.
I still really feel that sharing space ships between each project will be a good idea for productivity.
Sure thing - the more common resources the better!
BTW could you post the 3DS file for the Manta so’s I can check the JPCT loader? All being well I’ll put it in the feasibility test applet.
Here is a link for the manta model.
manta.zip
The zip file includes:
primary “.obj”: mesh
low poly “.obj”: extremely low poly (I use this for long distance objects). It could also be used for collision checking.
manta.jpg: primary texture map
manta_h.jpg: height map used with shaders
manta_n.jpg: normal map used with shaders
edit: Sorry its not in 3DS format, I use obj in my game. Blender can convert from obj to 3DS, in case you needed to.
Cheers bobjob! Seems to be some problems with the JPCT loaders though (even with jpct-supplied 3ds files) 
BTW Must-read article on procedural textures for planets!
yeah cheers bobjob
Whew! It was a struggle but I finally persuaded JPCT to play along - new feasibility test with the Manta in wobbly orbit.
NB: JPCT can only handle 256x256 textures. I haven’t done any texture-alignment tests yet…
EDIT: someone just pointed out that the thread title is spelled wrong! Hmm… how do you amend a thread title?
Ooo!! I know this one! ;D Just modify the first post and change its subject.
It works! Thx!
Just checked & JPCT seems to handle texture-mapping correctly.
[quote]new feasibility test
[/quote]
60fps on my Linux laptop using the software openGL renderer (my gfx card is broken). Very very nice.
Erm, could you upload your source to the svn repository. Just whack it all in a directory called feasibility test 1 or something, no need to tidy. (or post the source in a zip somewhere here).
I’ll use it as a base for the physics development at the weekend.
Tom
Hmmm… It’s locked to 60fps max but I only get 35fps here - we may need to keep an eye on this, maybe lock to 20fps or something?
I’ve added an attempt at particles, not sure this is the best way to do it.
Source code here (and no scoffing at my coding!).
60fps for me, and rather cute it looks too!
Bit of tinkering with procedural textures (source here).
Looks quite nice, but JPCTs spherical mapping seems a bit odd…
maybe also try use the decimated version of the model (in the zip i sent), rendered with a color value of r=0.5 g=0.5 b=0.5
or even maybe use the current model, without a texture, just the static color, when its far from the camera.
A bit more tinkering: a couple of tracking cameras (& probably the worst starfield bodge ever perpetrated!)
it is starting to look like a space sim.
I find it odd that JPCT is rendering the space craft when it is obscured by the earth. (in wire frame mode)
It seems like a candidate for performance slow down when many objects on the screen.