[Genma Saotome]

Question: When one creates several models, each with their own LOD values, and then groups them together for placement as a single complex shape, what, if anything does OR do?


I'm asking out of curiosity spawned from some of the large building models I've made... whole city blocks contained in a single .s file and what got me wondering about the old MSTS complex box idea was this: If my model has 1 tall skyscraper, 650ft tall and the rest of the block has a number of smaller buildings, none over 100 feet, isn't the bounding box for the whole model 1 city block in area raised to a height of at least 650 feet? Whereas I believe if it was all done in a complex box method each defined box in that set might have its own bounding box and perhaps even it's own LOD point of origin -- at least that is what I think was going on in MSTS -- and so the result should be that one portion of the city block has a bounding box rising 650 feet but other portions are down around 100 feet.

I know OR isn't doing much w/ bounding boxes now but in future if something is added to keep cameras out of models it seems to me that being able to have a collection of bounding boxes has great value for instances like the one I described above.

Also, from the route builders perspective, faced with building a model of a building that is 1000 - 1400 feet long (I've made several of these) I've always chosen to build it as one and break them up into several for placement... that makes a HUGE difference in the LOD's rational as now I have multiple origins... but in doing that it makes accurate placement a real challenge and, of course, any duplication of textures results in more draw calls. But the real problem is that placement of such sets of models as individual .s files is impossible w/o the Object Rotater spreadsheet... and heaven help you if later on you have to rotate them all, even with the spreadsheet.

[gpz]

An opinion about the last topic: I think saving a drawcall is the most important thing a modeler can do. That has a performance gain as if the model were less by thousands of polygons. Saving drawcalls by grouping buildings should be preferred even if it means one must drop LOD levels for them. Drawing additional polygons in the same drawcall is very cheap for the graphics hardware, while making a new drawcall is expensive.

[James Ross]

Genma Saotome, on 01 October 2013 - 09:40 PM, said:

Question: When one creates several models, each with their own LOD values, and then groups them together for placement as a single complex shape, what, if anything does OR do?

I do not actually know; I have not seen nor examined ESD_Complex. I do not believe OR reads/uses any data it may contain, though, and will probably treat the single shape file as just one big model.

Genma Saotome, on 01 October 2013 - 09:40 PM, said:

Whereas I believe if it was all done in a complex box method each defined box in that set might have its own bounding box and perhaps even it's own LOD point of origin -- at least that is what I think was going on in MSTS -- and so the result should be that one portion of the city block has a bounding box rising 650 feet but other portions are down around 100 feet.

Interesting information on MSTS; I'd love to see such a shape in action in MSTS and to look inside it, so do you happen to know any examples?

Genma Saotome, on 01 October 2013 - 09:40 PM, said:

I know OR isn't doing much w/ bounding boxes now but in future if something is added to keep cameras out of models it seems to me that being able to have a collection of bounding boxes has great value for instances like the one I described above.

Yeah, if we can define multiple bounding boxes/spheres/whatever for a single model inside the shape file, I'd prefer people to do so for exactly the kind of reason you mention - we can get better results with better data. :jawdrop2:

[wacampbell]

The .s file format supports a separate bounding sphere for each subobject, however, unfortunately many of the exporters don't use the feature and I believe OR doesn't either.

I'll add that with OR, there is little benefit - frame rate, memory or otherwise - to consolidating multiple buildings into a single shape file. Unless, your intent is to reduce them to a single batch call in which case they would have to share LOD and bounding spheres anyway. I suspect you're taking this approach more to overcome the RE limitation on object count per tile - a limitation that OR probably won't have in its eventual RE.

[Genma Saotome]

wacampbell, on 02 October 2013 - 06:03 AM, said:

The .s file format supports a separate bounding sphere for each subobject, however, unfortunately many of the exporters don't use the feature and I believe OR doesn't either.

I'll add that with OR, there is little benefit - frame rate, memory or otherwise - to consolidating multiple buildings into a single shape file. Unless, your intent is to reduce them to a single batch call in which case they would have to share LOD and bounding spheres anyway. I suspect you're taking this approach more to overcome the RE limitation on object count per tile - a limitation that OR probably won't have in its eventual RE.

I have several motivations:

• to use the same texture across multiple buildings, thereby reducing the number of draw calls.
  
• to ensure all of the buildings are located correctly relative to each other.
  
• to reduce the individual .s file count in the world file.

The first and second issues apply to both MSTS and OR, the third to MSTS... perhaps not to OR.

The downside to city block sized models are:

• One big bounding box
  
• One common origin has an effect on what you do w/ LOD's, often increasing inefficiencies -- either more LOD levels or small stuff near the origin being displayed so identical faces at the margins can be seen.

The first item isn't an issue (yet) in OR... if camera bumping is never developed it's not an issue at all. The second item remains true to both MSTS and OR.

When I consider this topic in the whole I'm left with a notion that I should be building models differently... not by city block but instead by all those faces in some close proximity that share a common texture (to minimize draw calls) with the result that models might span a much larger area... say, 4 x 4 city blocks... with one model that uses just a concrete texture, another model that uses just a red brick texture, a different model that uses just a brown brick texture, and so on. That would, in effect force OR to be doing draw calls in texture order instead of draw calls in model-texture order. I'd wind up w/ more models (a number equal to the number of texture files in use, vs. 16 city block sized models for a 4 x 4 city block area)... but it might result in better performance because the total number of draw calls would be lower by virtue of moving shared textures from many models (each model requiring it's own draw call for that shared texture) into a situation where each shared texture is now in just one model and so it requires only one draw call.

[wacampbell]

Genma Saotome, on 02 October 2013 - 10:16 AM, said:

[*]to use the same texture across multiple buildings, thereby reducing the number of draw calls.
...
[*]One common origin has an effect on what you do w/ LOD's, often increasing inefficiencies

This is a well known tradeoff for any mesh consolidation strategy. My preference is for OR not to burden the content artist with the decision wrt LOD's or batching. The content artist builds models separately or together as convenient. Leave it to OR to make the decisions on whether mesh consolidation and the LOD tradeoffs are worth doing. In an ideal world, OR will make that decision intelligently based on the amount of video ram, what else is in the scene etc. eg, For some user hardware, instancing may be a better strategy than mesh consolidation. Again OR is in the best position to decide. And I think most content artists would prefer not to have to think about batching etc anyway.

[Genma Saotome]

wacampbell, on 02 October 2013 - 10:30 AM, said:

Leave it to OR to make the decisions on whether mesh consolidation and the LOD tradeoffs are worth doing.

I understand... but OR doesn't do that now and I suspect it will be a very long time before it does. I may be wrong... but it also sounds like a non-trivial analysis and design task.

Aside from the specific content of this thread, I am concerned in general over the degradation of performance we've seen in OR over the last 12-15 months. We added necessary features... but at a pretty large cost. IMO we cannot afford to loose much more w/o also degrading interest in what the team is doing.

[wacampbell]

Genma Saotome, on 02 October 2013 - 10:41 AM, said:

but OR doesn't do that now and I suspect it will be a very long time before it does.

Yah, wishful thinking perhaps...

Quote

I may be wrong... but it also sounds like a non-trivial analysis and design task.

Potentially complex for the ultimate algorithm, but useful gains could be had with some simple methods and it could evolve from there.

[captain_bazza]

Blame the complexity of steam locomotive models on the original builders. There is no simple method of constructing, or reproducing, we use modeling techniques that works....unless you want to go back to the standard of MSTS default equipment....look at the Flying Scotsman in ShapeView and you will see what I mean. Remember that Kuju provided no information about actual construction, and anyway, their original method has been well superseded by hardwon add on modeler experience and experimentation, as well as huge leaps in hardware and software since 2001.

Strangely, although they might have their limitations, ACE and S formats still work and (seem) better than they did in the past. As far as I recollect, the Kuju S format was altered version of the MS X format, optimised for MSTS.

A couple of additional 'tools' would be of help, bump maps and shaders*.

*Not sure if that's the correct name - I'm refering to the ability to add effects such as a metalic look to side rods and varying degrees of 'gloss' to a model.

Let's not get too 'clever' with new modeling requirements to the stage that it turns off modelers from participating in the future development of OR.

Cheers Bazza

[captain_bazza]

I believe Dave is refering to the complex bounding box setup, of the type required to prevent smoke showing through a scenery model, such as a tunnel, bridge or station building. Some scenery models don't appear to have SD files at all. The main use seems to be for 'collision' purposes. There were some road infill shapes (placed between rails and tracks) such as the default MP, where the BB collision caused train separation after impacting with the BB of a rollingstock shape..

My advice would be to stay away from such complex BBs unless it applied to the above mentioned shapes. I don't believe you require anything other than a simplistic BB, or indeed, non at all. (I've used a BB in an SD with all coordinates set to 0, thus no chance of collisions occuring.

Cheers Bazza