The modelling quality discussion thread

[ElChristou]

Maxim, those links are really interesant, but I still have doubts on the result with models composed with a big quantity of meshes... Note that all example in those pages are done with single meshes...

****

Guys, I have done a MiniTut in a new thread because several idea are presented in this one. If you want to talk only about modeling, let's go there

http://www.celestiaproject.net/forum/viewtopic ... 7962#57962

[Toti]

Maxim,

Yes, thanks for those links, they are very interesting; especially the first one.


ElChristou,

in the linked articles you can see that the profile of the simplified meshes has changed substantially WRT the original.
So probably it won't be useful for certain cases, like with your shuttle cabin-hull intersection, where the concurrent meshes won't adjust anymore.
But maybe you could merge them before decimation, since material correspondence is usually treated with special care by these simplifiers.
Anyway the first candidates to decimate are the almost coplanar consecutive faces of the hull and bay doors, for example. These add a lot of complexity to the model and aren't needed in a lower poly version.

[ElChristou]

To illustrate my fear:

In red no problem, the decimation will be done correctly.
BUT in the case of 2 meshes (simulating one -blue/yellow) what will define the way the points of the meshes will be merged? In that case they must follow the same rythm or the integrity of the model is lost... (2 solution of wrong decimations)

[Toti]

To illustrate my fear:

In red no problem, the decimation will be done correctly.
BUT in the case of 2 meshes (simulating one -blue/yellow) what will define the way the points of the meshes will be merged? In that case they must follow the same rythm or the integrity of the model is lost... (2 solution of wrong decimations)

That is exactly what I described in my previous post.

Within the CMOD conversion Tool, there are several options to select. Two of them are puzzling me :

- Weld vertices
- Optimize Triangle lists to strips.

What do they mean ? What are they doing exactly ?

This is from the cmod tools README:

Weld vertices
This operation is relevant only when generating new normals or tangents for
a model. It causes vertices with identical positions to be treated as
identical for normal/tangent generation even if they have other attributes
that differ. It's most commonly used to eliminate ugly creases from models
that have cylindrically wrapping texture coordinates. Although it may slightly
increase the time required to modify a cmod file, it's usually desirable to
enable vertex welding.


Optimize triangle lists to strips
This option is only available when cmodfix has be built with NVIDIA's
NvTriStrip library (http://developer.nvidia.com/object/nvtr ... brary.html)
It converts triangle lists in a cmod file into much more efficient triangle
lists. Converting lists to strips often has a profound impact on rendering
performance. Calculating optimal triangle lists can be a slow process for
large models: it could take a minute to process a one million triangle model.

[ElChristou]

To illustrate my idea of level for meshes:



Let's imagine we can create this system level:

In pict 1, those numbers will have a level 0, the body of the module a level 5. At this distance, the poly count is 5184.

Pict 2, level 0 is not drawn. Poly count: 5090

Pict 3, level 0 and 1 are not drawn. Poly count: 3944

Pict 4, level 0,1,2 and 3 are not drawn. Poly count: 2520


Imagine on the whole shuttle, the gain can be quite good whitout losing any geometry.
The problem is this need a tool for post treatment after the modelling where the meshes would be "marked" with a level (the cmod format could become more efficiant this way). Note the black spot in the center of the door, it should have level 5, because of the high contrast -> stay visisble from far...

[maxim]

So you`d like to force celestia to draw different groups of meshes depending on the distance to camera. As I understand this mesh classification has to be made by hand.

It requires additional format definitions for cmod and a change in the renderer code so it skips data on a distance constraint.

But then it`s almost the same effort to define a hierachical mesh model, where different meshes for different LOD stages are stored. That would greatly reduce polycont. Not only 50% from highest to lowest level, but perhaps about 500%. And the hierachy could be generated automatically.

maxim

[ElChristou]

So you`d like to force celestia to draw different groups of meshes depending on the distance to camera.

This is just an idea...

As I understand this mesh classification has to be made by hand.

Definitively yes. Sure it's not practical to convert all the models on ML, but for new creations, it's the guarantie of a total control of the result.

It requires additional format definitions for cmod and a change in the renderer code so it skips data on a distance constraint.

Yes, BTW this can *perhaps* become a good way to create a really exclusive format.

But then it`s almost the same effort to define a hierachical mesh model, where different meshes for different LOD stages are stored. That would greatly reduce polycont. Not only 50% from highest to lowest level, but perhaps about 500%. And the hierachy could be generated automatically.

Don't take the example above numbers as an absolute reference. I think the gain can vary substancialy depending on the models.

On the shuttle doors closed + Flight deck, the model at the higher level of details would be rendered with 102823 poly; at lower level with 41799 which is aprox a 60% gain. For the shuttle payload open, the gain would be much important due to much more little meshes (If I recall we are passing 230000... so perhaps aprox 75% gain...). In all case the number of 41799 cannot be reduced.

I suppose the automated hierachy you are suggesting would be based on size or poly count, but as I pointed on the above example, some exeption can exist like strong contrast in color or form... what about those case?

[Slalomsk8er]

I suppose the automated hierachy you are suggesting would be based on size or poly count, but as I pointed on the above example, some exeption can exist like strong contrast in color or form... what about those case?

This a job for a texture as the inside of the door would be a texture at about level 2.5 (this is my way of doing things in blender).

I need a CMOD export script for blender a realy good 3D tool. It is pitty I have no time to code on but never loose your hopes.

[rthorvald]

So you`d like to force celestia to draw different groups of meshes depending on the distance to camera. As I understand this mesh classification has to be made by hand

It would be a very cool functionality to have. For now, i??d gladly settle for hires/medres/lores directories in the models folder, though. Isn??t that a more realistic request? It seems much simpler to implement, without me knowing what i am talking about, of course..

-rthorvald

[rthorvald]

There??s a difference between imperfection and planned, designed simplicity. An impressionist painting isn??t neccecarily faulty just because it suggests more than showing stuff....

I agree with the concept, but in practice it's not so easy.

It depends... In a model such as your wonderful shuttle, no. But on that, your goal is absolute realism and extreme detail. As a counter-example, the past year i have been mostly concerned with ways to integrate landscape models with virtual textures as seamlessly as possible. Here it makes very much sense to use a high-poly model in the center and cruder ones further away. It can work very well, too: for example in my Heimdall crater, the only substantial model stuff is the crater walls. The mountain ranges in the distance are just a few huge polygons textured like the VT... And the illusion works. Why Cham wants to examine those in detail i don??t understand, since it??s only function is to support the VT.

We can talk about aesthetic, design, simplicity etc, to find a good way of representation, but as this depend a lot on people taste, and as we are not working on a specific project I think we cannot generalize this for futur very different works.

Ok. But generalizing a little: optimizing a model for Celestia, interesting topics include such things as:

- removing hidden geometry for lighter models
- blending the model with it??s environment
- optimizing a model for a given set of computer configurations:
... The last one is particulary interesting to me: for example, i have found that my nvidia 5200 card with 64MB of vram can handle a single 3ds file up to about 15-20 MB before it breaks down. It would be interesting to perform an experiment, and see what the average Celestia user??s capability is. I mean, distribute a model in various levels of complexity, and get a broad feedback on how it behaves... To derive some general guidelines for Celestia model design.

-rthorvald

[maxim]

I mean, distribute a model in various levels of complexity, and get a broad feedback on how it behaves... To derive some general guidelines for Celestia model design.

A possible way to get system capability overviews. But (as I already said to Cham) if you'd like to have good comparable results, you should provide a cruising script. And - the easier it can be 'quicktested' the more answers ou'll get.

For an example of x models I'd propose setting up a starsystem with x planets - same specs, same texture - orbiting a star and beeing orbited each by one resolution version of the model. Then setting up a script that consecutively approaches the models in always the same way, and let the user watch fps rate changes.

maxim

[maxim]

As a counter-example, the past year i have been mostly concerned with ways to integrate landscape models with virtual textures as seamlessly as possible. Here it makes very much sense to use a high-poly model in the center and cruder ones further away. It can work very well, too: for example in my Heimdall crater, the only substantial model stuff is the crater walls. The mountain ranges in the distance are just a few huge polygons textured like the VT... And the illusion works. Why Cham wants to examine those in detail i don??t understand, since it??s only function is to support the VT.

The above like to the blender 'decimate' tutorial shows a nice example of nearly invisible mesh reductions on landscapes (72110 polys -> 10800 polys)

maxim

[maxim]

Sorry, it seems that I can't put anwers into one post

So you`d like to force celestia to draw different groups of meshes depending on the distance to camera.

This is just an idea...

No problem. Just wanted to state that this seems to imply no change on the render engine code, but 'just' on the code for data organisation and data format readin.

So you`d like to force celestia to draw different groups of meshes depending on the distance to camera. As I understand this mesh classification has to be made by hand

It would be a very cool functionality to have. For now, i??d gladly settle for hires/medres/lores directories in the models folder, though. Isn??t that a more realistic request? It seems much simpler to implement, without me knowing what i am talking about, of course..

Also implies changes on data organisation and readin. Should be a similar efford.

maxim

[ElChristou]

...For now, i??d gladly settle for hires/medres/lores directories in the models folder, though. Isn??t that a more realistic request? It seems much simpler to implement,...

Using 3 level of resolution may (in some case) imply triple work for creators; with a texture it?€™s easy to scale down a file, with a model sometime you will have to redo the work from scratch?€¦

It?€™s a much more realistic request, but if we can find some more deep solutions, it would be cool; unfortunately I?€™m afraid coders won?€™t follow, as the topic seems to point to some change not only in the data treatment but perhaps in the engine?€¦

There??s a difference between imperfection and planned, designed simplicity. An impressionist painting isn??t neccecarily faulty just because it suggests more than showing stuff....

I agree with the concept, but in practice it's not so easy.

It depends... In a model such as your wonderful shuttle, no. But on that, your goal is absolute realism and extreme detail. As a counter-example, the past year i have been mostly concerned with ways to integrate landscape models with virtual textures as seamlessly as possible. Here it makes very much sense to use a high-poly model in the center and cruder ones further away. It can work very well, too: for example in my Heimdall crater, the only substantial model stuff is the crater walls. The mountain ranges in the distance are just a few huge polygons textured like the VT... And the illusion works. Why Cham wants to examine those in detail i don??t understand, since it??s only function is to support the VT.

You?€™re point is good, and I the case of your addons it?€™s perfect. This illustrates perfectly difference of approach depending on the subject threaten.
I also understand Cham; Imagine you want to create and easter egg; the users will have to explore the zone to find it, and then too coarse meshes won?€™t be esthetic; this ist just an example, what I mean is that the principe of 3D is to give the freedom of examining things under all angles and distances.
In think the concept you have developed with your addons is something between 2D and 3D (a 3D model to create a nice 2D scene).

- blending the model with it??s environment?€¦

This is an entire topic?€¦ IMO the Celestia engine has too much bugs not yet solves which create to much work (tricks) to gain a good result?€¦ it?€™s why personally for now I prefer working on spacecraft?€¦
I think you are the indicated to alk about this because of your many experiences...

A possible way to get system capability overviews. But (as I already said to Cham) if you'd like to have good comparable results, you should provide a cruising script. And - the easier it can be 'quicktested' the more answers ou'll get.

For an example of x models I'd propose setting up a starsystem with x planets - same specs, same texture - orbiting a star and beeing orbited each by one resolution version of the model. Then setting up a script that consecutively approaches the models in always the same way, and let the user watch fps rate changes.

Yes this is an excellent idea, an addon for testing model purpose?€¦
Maxim, are you able to do that?

[maxim]

Maxim, are you able to do that?

Not before next month.

maxim

[rthorvald]

Maxim, are you able to do that?

Not before next month

If someone volunteer to write the script, i can write the ssc and set up the solar system. I can also host it, and write a webpage for download and to collect feedback via a form with pre-defined questions, to make it simpler for people to respond and for us to categorize the data that hopefully comes in.

El Christou,you wouldn??t by any chance have simple, complex and ultra-complex space shuttle versions we could use?

Is there any point in testing both 3ds and cmod versions?

-rthorvald

[ElChristou]

Maxim, are you able to do that?

Not before next month

If someone volunteer to write the script, i can write the ssc and set up the solar system. I can also host it, and write a webpage for download and to collect feedback via a form with pre-defined questions, to make it simpler for people to respond and for us to categorize the data that hopefully comes in.

Unfortunatly I cannot write the script... in fact we need 3 (or more scripts) one pointing to a model far from any planet (far from use of memory for textures), one pointing to a model orbiting at good distance a planet, and one pointing to a model at the surface of another one. The idea of the webpage and form is exellent.

El Christou,you wouldn??t by any chance have simple, complex and ultra-complex space shuttle versions we could use?

More complex than the actual one... beuh... no. A low version is easy to do, but in all case wathever model can be use for test... (and I think test must be done with several kind of models including some of ML)

Is there any point in testing both 3ds and cmod versions?

I think not really, but a test can be done to see if there is some kind of differences...

Now it would be cool to target some kind of config for the test; for this we need several kind of boards (32, 64, 128 etc) + several kind of config, 256, 512, 1G etc ram... Also if test can be done on all patform, better.

But also the most important is to have... something to test!!!
Who is able to dev those ideas? (Res folder for meshes, level of details, automated decimation) Maxim? (in fact I'm sorry but I don't really know your abilities ) others?

PS: Guys before beginning such a work I would like to end the shuttle... I need a few days to do this, so meanwhile it would cool to find some real solutions to transform those cool ideas in action...

[ElChristou]

BTW, if we can implement some good solutions for the optimization of FPS with models, I think most probably we will have a brand new Hires... ISS...

[maxim]

Unfortunatly I cannot write the script... in fact we need 3 (or more scripts) one pointing to a model far from any planet (far from use of memory for textures), one pointing to a model orbiting at good distance a planet, and one pointing to a model at the surface of another one. The idea of the webpage and form is exellent.

If you can wait 'till I'm back from holidays I can do a CELX Script.

We do only need one script that visits the different models consecutively. Without planet it's not a real test scenario. We can do a script move without model instead to get comparable framerates. I'd need a multires test model btw. - Voyager or DS9 may be good examples.

What I'd also like to have for that is a fps readout func - something like 'getfps()' for Lua! Harry?

Is there any point in testing both 3ds and cmod versions?

3ds is much slower - perhaps to get a quantifier.

Who is able to dev those ideas? (Res folder for meshes, level of details, automated decimation) Maxim? (in fact I'm sorry but I don't really know your abilities ) others?

It's primarily a question of spare time. I the first run we don't need code. Only some models reduced with blenders decimation function.

maxim

[ElChristou]

...We do only need one script that visits the different models consecutively. Without planet it's not a real test scenario. We can do a script move without model instead to get comparable framerates. I'd need a multires test model btw. - Voyager or DS9 may be good examples.

A unique script visiting the different models will be a time consuming if we only need info on last model...

I will do a first test model in 3 levels. Guys do not wait some kind of "wondrfull artwork" just something (perhaps strange) to test FPS...