Why use High Poly - Sketch Up ... instead of learnig GMax & Blender

[Milwaukeeroad261]

I can understand everyones anger, but at the same time you must realize that poly count is important. not everyone has a tower or a really strong laptop. it's not just a do what you want leave it at that kind of scenario. If this turns into a little kids war over who creates what the best (which it kind of already has) then it's almost pointless to even make stuff for trainz, now is it?

have fun fighting.

-AJ

 

[Dinorius_Redundicus]

The size comes into it as the overhead per asset is roughly 500 poly equivalents so if you create an asset of four houses then you only get one overhead but the poly count will be four times that of a single house. KUID: 86627:100029 is of this type.

Cheerio John

..which I take as another reason not to talk about 'poly equivalents' but rather to list both poly's and textures separately, as ns37 was advocating.

My question about images versus materials was not answered at all by this. Can someone give a clear ruling on whether its the number of images, the number of materials, or some sort of combination of both that matters?

My secondary point about poly's-per-volume was also slightly missed. If I made a 1 cubic metre box, the poly density would be 12 triangles per cubic metre. If I scaled the same box up to 100 cu. metre, the poly density would drop to 0.12, but so what? The computer still has to render those 12 polys. That's why I think poly density is a useless criterion.

 

[Retro00064]

I have just one question:

If you create a parrot in GMAX, is that considered just one polly?

LMHO! Genius! :hehe:

 

[mezzoprezzo]

Gramatical error

Ed isn’t being accurate with the spelling.

In cyber modelling the term is not “polly”, it is “poly” – a shorter word.

A “poly” must therefore be a parrot with no legs.

 

[narrowgauge]

Re Poly

It is short for politician. A bird with no brains

Peter

 

[Euphod]

I have just one question:

If you create a parrot in GMAX, is that considered just one polly?

Ed isn’t being accurate with the spelling.

In cyber modelling the term is not “polly”, it is “poly” – a shorter word.

A “poly” must therefore be a parrot with no legs.

Re Poly

It is short for politician. A bird with no brains

Peter

Great... we can't even agree on that! Have fun fighting....:hehe:

 

[Jananton]

Hmm, maybe let's have a poll if it's polly's or poly's then. :hehe:

Greetings from overcast Amsterdam,

Jan

 

[gawpo50]

polly want a cracker

I couldn't contain my polly self.....

 

[whitepass]

It's number of materials not textures, that is why normal maps are usable.

 

[johnwhelan]

Originally Posted by johnwhelan
The size comes into it as the overhead per asset is roughly 500 poly equivalents so if you create an asset of four houses then you only get one overhead but the poly count will be four times that of a single house. KUID: 86627:100029 is of this type.

Cheerio John

..which I take as another reason not to talk about 'poly equivalents' but rather to list both poly's and textures separately, as ns37 was advocating.

My question about images versus materials was not answered at all by this. Can someone give a clear ruling on whether its the number of images, the number of materials, or some sort of combination of both that matters?

My secondary point about poly's-per-volume was also slightly missed. If I made a 1 cubic metre box, the poly density would be 12 triangles per cubic metre. If I scaled the same box up to 100 cu. metre, the poly density would drop to 0.12, but so what? The computer still has to render those 12 polys. That's why I think poly density is a useless criterion.

When a scene is rendered on the screen then the total number of polygons in the scene matters together with the total size of the materials. Desert scenes typically are easier on the computer than built up areas.

Each asset in the scene adds to the total load. In the case of kuid:86627:100029 the number of polygons is the same as four separate houses would be. However since they share the same material the overhead associated with the material or texture is only 200 poly equivalents not 4 * this amount. Additionally because only one mesh is loaded there is only one overhead of 300 poly equivalents not 4.

If you use fewer larger assets to fill the scene then the machine load is lower than using more smaller assets even if the number of polygons is the same which is why the poly's-per-volume is relevant.

The poly equivalent overhead is in addition to the number of real polygons.

Cheerio John

 

[Retro00064]

Re Poly

It is short for politician. A bird with no brains

Peter

That's because the polytics ate their brains!

Thanks for the laugh, Peter.

 

[peghorse]

Hexagon makes great models. You then take them and run them through Blender or Sketch-up to make a Trainz (Jet) compatible file. I did that with the small strip mall my bro and I worked on a few Trainz versions ago. Back then we made the model in Amapi Pro which became Hexagon. Once the model was made, we exported it to a 3ds and ran it quickly through GMax. It's the same idea.

John

Thanks John! I was hoping a knowledgeable person would clarify that.

 

[Dinorius_Redundicus]

Originally Posted by johnwhelan
If you use fewer larger assets to fill the scene then the machine load is lower than using more smaller assets even if the number of polygons is the same which is why the poly's-per-volume is relevant.

Cheerio John

If the number of poly's in the scene is the same, then the only difference is the number of textures (actually materials) used. I can see that using a single texture for multiple meshes would lower the 'poly equivalent' load, but I still can't see how the physical size (volume) of the asset in the scene matters. It's just how many polys and how many materials are in it. Anyway, perhaps this is veering too far off topic and is something we could discuss by PM sometime or just agree to disagree on. It has very little to do with SketchUp.

 

[johnwhelan]

If the number of poly's in the scene is the same, then the only difference is the number of textures (actually materials) used. I can see that using a single texture for multiple meshes would lower the 'poly equivalent' load, but I still can't see how the physical size (volume) of the asset in the scene matters. It's just how many polys and how many materials are in it. Anyway, perhaps this is veering too far off topic and is something we could discuss by PM sometime or just agree to disagree on. It has very little to do with SketchUp.

Trainz is software and needs to keep track of each asset and that's where the additional overhead comes from, it's merely expressed in terms of the equivalent number of polys. If you do a search for posts by WindWalkr you'll find the N3V explanation.

It is relevant as it is one of the things you have to take into account when creating content no matter which software is used. ie when is lod worth while.

Cheerio John

 

[PEV]

So Ed, we could be talking about polys per polly if we were being pedantic.

 

[mezzoprezzo]

I'm still waiting for the polly poly poll!

 

[norfolksouthern37]

If you use fewer larger assets to fill the scene then the machine load is lower than using more smaller assets even if the number of polygons is the same which is why the poly's-per-volume is relevant.

This might be relevant, but who would set the mean standard to follow? i certainly agree that a 10,000 polygon warehouse is better than a 10,000 polygon streetlamp in that regard, but there would have to be some kind of standard by which to say "that is too much". i think that comes down to asset creator education more than anything. if they were doing things the correct way, there would be no reason to worry about this.

The poly equivalent overhead is in addition to the number of real polygons.

There might be an equivalent to load on the graphics engine, but there are never any more polygons than the 'real' ones like you are calling them. even giving people this idea is a mistake far as i am concerned.

Trainz is software and needs to keep track of each asset and that's where the additional overhead comes from, it's merely expressed in terms of the equivalent number of polys. If you do a search for posts by WindWalkr you'll find the N3V explanation.

Still shouldn't be a 'rule of thumb'. i think it was only expressed that way so you would know what it meant. again, i think this is a bad idea. i cannot think of an instance in all my years of creating 3d art for a number of softwares where one would be able to actually be specific about this number of so called 'equivalents' and where they wouldn't vary widely. also, to try and add this arbitrary number is just going half way - i.e. not taking into account several other things that could be producing overhead. the only real way to know any useful information about a model without making things up such as equivalents is something like

Polygon count:
Number of materials:
Number of texture maps:

To add anything else to that that isnt specifically known is a waste of screen space to be honest. also a lot of that information is already available in CMP.

 

[Konni]

Hi,

I would like to come back to the post by WindWalkr

What I'd personally like to see is a utility which can test a Trainz asset in a somewhat realistic usage, and report back on the real-world performance. For many objects, "how well does this one object perform?" is the wrong question. A much better question is "how well does this asset perform when spread across the map in a realistic scenario?" It would need to take into account LOD, loading time, buffer usage, memory usage, effect on frame rate, etc.

Of course, that only answers the performance question. Whether the object works as expected and looks nice are completely separate questions.

chris

A utility which asesses content might be a good solution, but its working must be based on reasonable principles. If N3V shrinks from eliminating crap from their servers, the utility might at least be used to flag assets as potentially troublesome if they do not meet standards. The standards need to easily verifyable like the following:


1. all scenery, buildable, industry and traincar assets with more than 200 polys must have lod.
2. poly counts between differnt lod-levels must differ by at least a factor of 2
3. If the highest poly mesh of an asset exceeds 10k, the number of poly per square metre ground area must not exceed 2k.

An additional standard about number of materials per asset (how about <10) might also be reasonable.

Cheers,

Konni

 

[amigacooke]

If N3V shrinks from eliminating crap from their servers,

I'd like to point out that 'crap' that I am interested in is more useful to me than the most efficient content that I have no use for.

Sure it would be great if the creator of the 'less efficient than it can be content' used all the techniques available, but perhaps they have done the best they can with the resources they have available.

 

[Konni]

I'd like to point out that 'crap' that I am interested in is more useful to me than the most efficient content that I have no use for.

I have already modiefied my views , that content that does not meet the specs I proposed should be flagged as potentially troublesome.

Cheers,

Konni