It will, but with a new generic model rendering, supported by a s3o importer. However in spring, 3DO and s3o each have their own structures, and are handled everywhere with lots of if-else, so its really hard to extend it normally..Does this mean osrts wont be using S3Os? What will osrts use?
Upspring 1.54
Moderator: Moderators
No, according to rattle or nemo, it works somewhat. However if there are still angles or distance units messed up, its a matter of scaling a few constants. If you're able to script in COB I think you can manage changing a few constants in a lua script as well 
Note that it won't give you an out-of-the-box animation or something, but that wasnt the goal.
Note that it won't give you an out-of-the-box animation or something, but that wasnt the goal.
The bos anim exporter works to some extent, and its helpful for seeing where your keyframes are in the bos, but really its probably easier to just read the angles from upspring and write the script yourself - the BOS exporter sometimes does strange things like negative speeds or negative sleeps. And you'd want to tweak all the speeds yourself anyways.
It is handy for getting a sense of the core movements and frames, so you can trim it down as much as possible, but I definitely wouldn't "plug and chug" and expect any kind of decent results.
It is handy for getting a sense of the core movements and frames, so you can trim it down as much as possible, but I definitely wouldn't "plug and chug" and expect any kind of decent results.
Why would add a feature that double or triple the necessary modding time which just increase very few thinghughperkins wrote:Yes, agreed. However that could change.maestro wrote:Unfortunately that is NOT the case...
the main cause of slowdown with hundreds tank is not 3D or graphic stuff, but pathfinding programs... LOD wont help....
S3O is a relatively new standard, and it could be easier to tweak it now to accept level of detail, than to create a new standard in a year or two once the pathfinder is optimized.
that would be really bad move... I would have to look for other engine for WD to avoid spending all the time doing spring model....Better stay 'KISS' way
today Spring is already too complex, not very strong and not entirely work...
And with the unlimited zoom and FPS mode ppl will start do the LOD to increase the detail so they still looks crisp at FPS close up
what a wrong way to develop RTS game....Now I like Blitzkrieg and they DONT CARE about FPS, superzoom, LOD, real reflection that make water map bitchy slow to play etc etc visual crap. ANd they still looks beautiful...
simplicity is the way!
Hi, find it doesnt work in my comp....TA 3D wrote:maestro:
Yes it is. Here is a link to all the files you would need to install the windows version (someone else did the compling and uploaded the installers for the public):
http://gimp-win.sourceforge.net/stable.html
[/url]
always hang whenever scanning font ?
I installed latest GTK and latest GIMP under winXP
Its perfectly possible to do automatically calculate various lower detail versions, or even do it in a continuous way (View-Independent Progressive Meshes). I've seen some really neat algorithms to generate low detail models, low detail skeletons and automatically generate model normal maps using gfx hardware. If I have enough time, that will all be supported in osrts.Why would add a feature that double or triple the necessary modding time which just increase very few thing that would be really bad move... I would have to look for other engine for WD to avoid spending all the time doing spring model....
I agree that forcing the modeller to make lod versions is a really stupid move, it just shows lazyness on the side of the programmer
Are you meaning generating them on-the-fly? Surely that's much more expensive than just swapping. Why not just build a tool that produces each LOD with the algorithm, and do the swapping in the standard way?jcnossen wrote:Its perfectly possible to do automatically calculate various lower detail versions, or even do it in a continuous way (View-Independent Progressive Meshes). I've seen some really neat algorithms to generate low detail models, low detail skeletons and automatically generate model normal maps using gfx hardware. If I have enough time, that will all be supported in osrts.Why would add a feature that double or triple the necessary modding time which just increase very few thing that would be really bad move... I would have to look for other engine for WD to avoid spending all the time doing spring model....
I agree that forcing the modeller to make lod versions is a really stupid move, it just shows lazyness on the side of the programmer
(infact why not do that for us poor spring modders who will have to wait some time to get our grubby mits on OSRTS?
)
)
@JC:
Personally, considering that the ideal polycount for a model in a RTS is still <1500 tris, I'd say that LODs are just kind've icing on a cake, and support for plugin shaders and normal maps is a bigger deal. It'd be nice, but hardly necessary. On the other hand, if the renderer didn't bother tesselating stuff with reflections or normal maps after reaching a certain distance from the camera frustrum, that'd actually be worth doing, because it'd save a lot of triangles and effectively result in LOD.
And, while I'm going on about silly stuff... now that I've looked at the source, there seems to be no solid reason we can't have multiple hitspheres and simply direct the hitscan result back to the parent... I see that you're messing with a hit mesh, too, like Freelancer used. If I may, I'd strongly suggest that you went with a model much closer to Freelancer's, and actually have the hitboxes be meshes users design... so that we can do this with low-poly, non-concave boxes. I'd just make a rule that any S3O model that includes an object whose name starts with "hitbox_" be treated as a hitbox, and make it the modeler's responsibility to make them closed, non-concave objects.... that'd also make it so that UpSpring could hide them once they were properly named, and parenting them to the rest of the model, so that they could obey animation code would then be done as well... just my $.02
Personally, considering that the ideal polycount for a model in a RTS is still <1500 tris, I'd say that LODs are just kind've icing on a cake, and support for plugin shaders and normal maps is a bigger deal. It'd be nice, but hardly necessary. On the other hand, if the renderer didn't bother tesselating stuff with reflections or normal maps after reaching a certain distance from the camera frustrum, that'd actually be worth doing, because it'd save a lot of triangles and effectively result in LOD.
And, while I'm going on about silly stuff... now that I've looked at the source, there seems to be no solid reason we can't have multiple hitspheres and simply direct the hitscan result back to the parent... I see that you're messing with a hit mesh, too, like Freelancer used. If I may, I'd strongly suggest that you went with a model much closer to Freelancer's, and actually have the hitboxes be meshes users design... so that we can do this with low-poly, non-concave boxes. I'd just make a rule that any S3O model that includes an object whose name starts with "hitbox_" be treated as a hitbox, and make it the modeler's responsibility to make them closed, non-concave objects.... that'd also make it so that UpSpring could hide them once they were properly named, and parenting them to the rest of the model, so that they could obey animation code would then be done as well... just my $.02
-
hughperkins
- AI Developer
- Posts: 836
- Joined: 17 Oct 2006, 04:14
Introduction to LoD
Quick introduction to LoD. LoD means changing the model according to how far away the viewer is. A commander viewed up close might use 4000 triangles to look good. This is the case with XTA armcom for example. When viewed from TAOverhead view, we dont need nearly so many triangles, and the extra triangles will only slow down the computer. It could be enough to have a model with just 20 or 30 triangles.
For map makers, LoD would allow a very detailed terrain that runs smoothly.
Observations on LoD
- generating LoD is difficult; probably better to do it from a modelling tool rather than on the fly
- S3O support for LoD does not oblige a mapper to use it. It's perfectly possible to create maps with single-LoD features. Of course, many people will prefer to use a map that both looks good and gives a good frame-rate
S3O format
S3O currently looks like:
s3oheader contains
--- one or more s3opieces
The s3oheader describes the textures and gives some global information on the object such as bounding box, height etc.
The s3opieces describe chunks of the model, such as the whole model, or a single arm or leg.
To add LoD support, we modify the format as follows:
s3oheader contains
--- one or more s3olods contains
--- --- one or more s3opieces
In the general case, we can have a single LoD containing a single piece. Modders and mappers who wish have the option to add an extra LoD, eg using an LoD generation tool.
We can make the format backwards compatible by incrementing the s3o version number.
Use of LoD by modders and mappers
Of course, modders and mappers dont see the internal binary structure of the s3o. The modelling tool can have a button such as "improve performance", which can automatically generate an extra LoD level or two using Jelmer's algorithm.
Mappers wouldnt need to know what LoD is, only that the map can support more features and more details whilst running at a higher frame-rate.
Quick introduction to LoD. LoD means changing the model according to how far away the viewer is. A commander viewed up close might use 4000 triangles to look good. This is the case with XTA armcom for example. When viewed from TAOverhead view, we dont need nearly so many triangles, and the extra triangles will only slow down the computer. It could be enough to have a model with just 20 or 30 triangles.
For map makers, LoD would allow a very detailed terrain that runs smoothly.
Observations on LoD
- generating LoD is difficult; probably better to do it from a modelling tool rather than on the fly
- S3O support for LoD does not oblige a mapper to use it. It's perfectly possible to create maps with single-LoD features. Of course, many people will prefer to use a map that both looks good and gives a good frame-rate
S3O format
S3O currently looks like:
s3oheader contains
--- one or more s3opieces
The s3oheader describes the textures and gives some global information on the object such as bounding box, height etc.
The s3opieces describe chunks of the model, such as the whole model, or a single arm or leg.
To add LoD support, we modify the format as follows:
s3oheader contains
--- one or more s3olods contains
--- --- one or more s3opieces
In the general case, we can have a single LoD containing a single piece. Modders and mappers who wish have the option to add an extra LoD, eg using an LoD generation tool.
We can make the format backwards compatible by incrementing the s3o version number.
Use of LoD by modders and mappers
Of course, modders and mappers dont see the internal binary structure of the s3o. The modelling tool can have a button such as "improve performance", which can automatically generate an extra LoD level or two using Jelmer's algorithm.
Mappers wouldnt need to know what LoD is, only that the map can support more features and more details whilst running at a higher frame-rate.
I am pretty dubious about automatic methods of generating LOD, when the initial meshes are as low-poly as they are, but I'll withhold judgement until I have a tool to test with. It's one thing to go from a 200K-triangle mesh to a 2K-triangle mesh... it's another thing entirely to go from 2K to 200... at 200, you're going to be losing a lot of essential geometry to maintain the rough shape, and I have no idea how you're supposed to not have it look terrible when animating... going down to, say, 30 tris is really optimistic- either it'd eat up a lot of GPU cycles making sure that those 30 tris were "close enough to not look like crap" or it'd, well... look like crap.
And there's also the issues of thresholds and edge tolerances, and other tricky stuff. For example, my latest version of the Knight model for NanoBlobs has 492 triangles. Which triangles aren't essential to the model? The answer to that is, "we could lose a few detail greebles and cut the six-sided gun down to three". But, what about stuff with a lot've curvature conveyed via welding? I'm finding it hard to believe that any automated LOD method would not tear them up and look terrible. That's one of the many reasons why LODs are, generally speaking, made from a very high-poly top LOD then optimized downwards, usually with a lot of hand-tweaking.
And there's also the issues of thresholds and edge tolerances, and other tricky stuff. For example, my latest version of the Knight model for NanoBlobs has 492 triangles. Which triangles aren't essential to the model? The answer to that is, "we could lose a few detail greebles and cut the six-sided gun down to three". But, what about stuff with a lot've curvature conveyed via welding? I'm finding it hard to believe that any automated LOD method would not tear them up and look terrible. That's one of the many reasons why LODs are, generally speaking, made from a very high-poly top LOD then optimized downwards, usually with a lot of hand-tweaking.
HI jcnossen....
I found flipping all polygon result in destroyed shading (all part extremely darkened).... so I flip it in Lightwave... Not a problem but some noob might wrongfully think that there is sthing wrong in their model
I have to do that because all Lightwave object will be flippen left-right when it imported to Spring so I try to flip it in Upspring (with 'resize X-axis, scale -1).....
WOnt delay the tutorial release date though (end of this week).... Just FYI :)
Otherwise... well, replacing some object with another sometimes crash it...
SO I put as many 'MAKE IT RIGHT FROM THE FIRST TIME' notes
I found flipping all polygon result in destroyed shading (all part extremely darkened).... so I flip it in Lightwave... Not a problem but some noob might wrongfully think that there is sthing wrong in their model
I have to do that because all Lightwave object will be flippen left-right when it imported to Spring so I try to flip it in Upspring (with 'resize X-axis, scale -1).....
WOnt delay the tutorial release date though (end of this week).... Just FYI :)
Otherwise... well, replacing some object with another sometimes crash it...
SO I put as many 'MAKE IT RIGHT FROM THE FIRST TIME' notes
maestro: Maybe "recalculate normals" fixes it? In any case its not fixed automatically, so I do agree its really a bug.
argh: as usual someone will just have to write an app that does the job and prove you wrong
Note that many papers have been written on visual error calculation and mesh lod. You can calculate exactly how much "error" there is in a mesh at a certain distance, and make sure it is below a requested value.
argh: as usual someone will just have to write an app that does the job and prove you wrong
Note that many papers have been written on visual error calculation and mesh lod. You can calculate exactly how much "error" there is in a mesh at a certain distance, and make sure it is below a requested value.
@JC:
Yeah, I'm reading one now: http://www.cg.tuwien.ac.at/studentwork/VisFoSe98/msh/
Looking through the available papers, I'm still pretty dubious. Even the articles I'm reading thus far seem to agree with my qualms about the problems of LOD generation on-the-fly, for things near the low-threshold levels and curved objects. I've seen LODs used in high-end raytracing applications, such as Brazil, but I can't think of when I've seen this used in a real-time application.
Has anybody used this in a commercial game engine? I mean... even HL2 used static LODs, generated by artists, rather than an automated method like the ones described here...
Yeah, I'm reading one now: http://www.cg.tuwien.ac.at/studentwork/VisFoSe98/msh/
Looking through the available papers, I'm still pretty dubious. Even the articles I'm reading thus far seem to agree with my qualms about the problems of LOD generation on-the-fly, for things near the low-threshold levels and curved objects. I've seen LODs used in high-end raytracing applications, such as Brazil, but I can't think of when I've seen this used in a real-time application.
Has anybody used this in a commercial game engine? I mean... even HL2 used static LODs, generated by artists, rather than an automated method like the ones described here...
I'm guessing yes, even directx8 had a vipm (continuous lod using progressive meshes) implementation.Has anybody used this in a commercial game engine? I mean... even HL2 used static LODs, generated by artists, rather than an automated method like the ones described here...
http://www.cbloom.com/3d/techdocs/vipm.txt
http://research.microsoft.com/~hoppe/pm.pdf
Erm, do the tools needed to create such a thing exist in the GPL domain? Will it work with multipart meshes? Will it correctly interpret hole boundries? I always figured such a thing would have to include hinting instructions... therefore, we come back to a chicken-and-egg issue, of whether or not it worth it to invest that much artist-time into an object, for stuff as low resolution as an RTS. Better yet, whether artists working for free, at relatively low skill levels, can be taught how to do so in a reasonable amount of time.How do we arrange the SSC computations to make this work? Well, the
whole VIPM is given a palette of matrices which correspond to the bones
of the character. Each vert has a SkinInfo structure which contains
several matrix palette indices and a weight for that matrix (typically
the weights on one vertex add up to one). So, after we have made all our
VIPM decisions and have a VB with some number of verts, we simply walk
through the SkinInfos for all those verts and do the SSC computation, to
find the vertex position and normal to jam in the VB. As with the rest
of the VIPM math, we only reference the prefix of the VB which will be
needed for rendering. This also lets us page in the SkinInfos from disk
as needed for higher detail.
Given when this was written, my first inclination as to who might've actually used this would be, "FarCry", because it was by far and away the most advanced rendering engine of the Direct3D 8/9 generation that I know of, in terms of LOD. But based on actually playing the game and observing it (I have not modded it, mind you, so I may just be ignorant here) it looked like they used static meshes for LODs.
<shrugs> at any rate, is this avenue of research and development worth more than putting a mesh-deformation and transform system that can be run from scripting engine commands into play? Because, frankly, that's the real prize, imo. But hey, it's your think time, and either way, if you can make it work out, it'll be cool to play with