Another model created in Google SketchUp...

[Dinorius_Redundicus]

I see a phrase like this in the description of every SketchUp/RubyTMIX asset; "The effective system load of this asset is 1800 polygons (300 from geometry, 1500 from textures)".

Is it valid, or just a way of disguising how many texture images or materials are used?

What is the basis for expressing texture load as a number of polygons?

How would such a rating relate to a statement of triangle count and number of materials? Or triangle count and draw calls?



.

[G.M.]

As I understand it (open to other views)
A Drawcall is like a separate command from your CPU to the GPU
now get this mesh(part) and this texture and show it on screen
don't think you can compare a drawcall to a exact number of polies
some say one drawcall comes close to 3k polies
But in all cases less is better cause there is a max ammount your GPU can put on screen at any time
each drawcall is a new set commands and loading of mesh and textures.

[pcas1986]

My understanding is -> You get a draw call for each 65k chunk of triangles assuming one material. Each material is a draw call. So if you had a mesh with 65k tris and ten materials that would be 10 draw calls. If you had a 100k mesh and one material it would be 2 draw calls.

The bad boy here is the number of materials but it isn't that simple. A very low poly LOD mesh using a 2048*2048 texture may be a worse performer than a low poly mesh with a 256*256 texture.

If you are interested there are more comments about draw calls in the TrainzDev forum going back a few years. AFAIK they still apply. Search on "draw call".

I don't understand why N3V hasn't created a simple tool that analyses an asset to point out where improvements could be made. You can, of course, use the Asset Preview which does give some indication and is what I use. Trying to do this with a loco is hard work given that attachments may have different LOD change distances from the main loco mesh.

The best rule is to aim for just one draw call at minimum LOD - i.e. way out in the distance.

BTW, I have seen those comments in Sketchup/RubyTMix assets and they don't make any sense to me. A texture is just an image mapped to a mesh, it doesn't by itself create more polygons (tris or ngons).

[johnwhelan]

A long time ago N3V posted 200 poly equivalents overhead per texture, 300 per mesh and it referenced GMAX with lots of small textures. It's probably based on that.

Cheerio John

[Frank_Dean]

Perhaps unrelated to the main topic of the thread.

Just as an example of the polygon waste of SketchUp objects through RubyTMIX and transferred to Trainz compared to a Gmax 1.2 object, almost the same size.

The sketchup building is completely flat, with no protrusions or incoming reliefs on all faces, taken from a download uploaded to DLS in the last few days.
The windows and doors are flat and are at the same level as the exterior walls.
I have put a view provided by Trainz Mesh Viewer 2 with the wire frame view, where only the polygons are visible and no textures are visible.
A single building is not a problem, but if you make a small city with only 100 buildings you will have: 100x310polys=31000polys to spare that are useless.

Automatic translation.

[G.M.]

True Frank
btw you can delete the bottom of the right house and make it 12 poly (jk)
the left mesh you can delete everything but the windows and make a night mesh with self ilumination


Worse is that those sketchup models have many textures and each texture makes a new drawcall
Understand that not everyone has the patience to learn a 3d prog
FI a route builder can't find that specific building he needs,
then a ready made sketchup is easy grabbed.
Think its up to us users, to select what we want to use

[JCitron]

I won't go into my dissertation on 256,000 faces found on miniature and nearly invisible machine feet unless someone wants to hear it.

Anyway, from what I was told Sketch-up models are natively B-spline and not polygon-based models. There is no mesh as we know it and the surfaces are more like a cloth wrapped around the frame. When the Ruby-Mix script translates the models, it converts these surfaces into polygons and their gazillion faces needed to represent the surface.

As mentioned, the other issue with Sketch-up models is the textures are applied the old-fashioned way using an individual texture for each face instead of using a UVW map. With each surface becoming a face during the conversion process, we now have a gazillion textures placed. For a large building that becomes a large issue because each and every window is drawn individually. This is a lot of overhead for both the CPU and the GPU to processes the draw-calls and then render the images on the mesh.

[Dinorius_Redundicus]

A long time ago N3V posted 200 poly equivalents overhead per texture, 300 per mesh and it referenced GMAX with lots of small textures. It's probably based on that.

Cheerio John

That rang a bell John, and I've investigated it a little further.

I downloaded 18 recent single-mesh Sketchup assets and analysed them for poly count and textures, compared to what the RubyTMIX descriptions say.

"System load from geometry" is simply the triangle count, as verified by PEV Mesh Viewer.

"System load from textures" is calculated from the number of textures. Since it's added directly to the actual triangle count to give a total system load, it's units must also be triangles (or "triangle equivalents"). I would still love to know how that equivalency between textures and triangles was derived and whether it's even approximately valid.

Here is the linear equation that RubyTMIX is apparently using to calculate texture load;


System load from textures = (Number of textures x 300) - 300




So it looks like the important factor is 300, not 200, but it’s basis is obscure.

The large white data point on the graph is not a measurement, but an extrapolation of the line to the X-axis. It means that, according to RubyTMIX, an asset with 1 texture has no "system load" from the texture (!). In reality, that cannot be right because 1 texture is at least 1 draw call. It would be more realistic if the line started at the 0,0 point, meaning no texture = no texture load. In other words, RubyTMIX's calculation systematically under-estimates the contribution of textures to the total load.

Also note that this linear relationship takes no account of how large or complex a texture material is (i.e. image sizes or number of maps involved, such as diffuse map, normal map etc). So it is definitely a very over-simplified measure.

Rearranging the equation gives this;

Number of textures = (System load from textures/300) + 1

For people downloading RubyTMIX assets from the DLS, you can read the texture load details from the asset description and calculate the number of textures involved before you decide to download. Anything over “300” for texture load means there are more than 2 textures. And remember that each texture is at least 1 draw call.


.

[Pendolino]

Years ago, Windwalkr stated that every additional texture was worth the equivalent of 300 extra polys in terms of system load. This is the source of the automatically generated warning in the "description" tag of any assets made in Sketchup and converted through RubyTMX. ModelerMJ was so kind to add this feature at a time when the DLS was flooded with huge-poly assets taken from the Sketchup warehouse.

@Frank Dean: thanks for showing the structure of a Sketchup-made asset in detail.

@Jcitron: I would like to hear about the 256k-poly mini-object, just to add it to my black list . So far, my favourite horror is a 28 k-poly trumpet...

[JCitron]

@Jcitron: I would like to hear about the 256k-poly mini-object, just to add it to my black list . So far, my favourite horror is a 28 k-poly trumpet...

Okay, Carlo here it is.

In the mid-1990s, I worked for a company that created interactive training programs for the plastics industry. We used a number of sources to produce the materials including 3d models created in 3ds Release 4 for DOS. We had a custom project to do for Gillette company, the famous company that makes men's razors if you're not familiar with them.

Included in the video was a walkthrough done of their plant up in Wilmington, MA showing their floor layout and injection molding machines on the floor. The file was a direct import from Auto Cad that imported fine other than a few coplanar faces and some flipped normals that created invisible spots. In addition to that was some already created handmade models of some generic molding machines. These were fully animated showing plastic pellets going into hoppers and had some Zigot people standing around. To make the scene look busy my coworker setup multiple machines instanced in the scene. Remember this was the 90s so we had to watch our memory budget.

My coworker assembled the Gillette plant walkthrough, added in a scene generated by the injection molding machines and set up the animation before we went home. We used my "older" '486 DX50 as a second render station while his "fast" Pentium 90 was the main machine. We went home thinking everything would be fine and expected everything to be rendered by the morning since the estimated time was 12 hours. We came in excited the next day to find the rendering had stopped. Remember, each frame is a single .tga file that gets assembled in sequence. Our rendering had whizzed right through the Gillette plant but stalled on the injection molding machines.

My coworker couldn't find anything unusual and called me in to take a look. I checked the network, which was the old coaxial will terminators, memory on the PCs and even defragged the hard drives again. Everything checked out fine. Setup the render again, thinking there was a power glitch or something weird, and went home. We got in the next day and the same thing happened! By now the boss is getting antsy and saying things he didn't really mean to say that included just fix it at the end. We kept looking around. Dan even had me look at his machine again and gave me a copy of the model to load up and look at. I had to borrow a dongle from the draw for that. There was nothing to see. After thinking about this I recommended disassembling the scene by hiding objects. We hid all kinds of stuff, but it didn't help such as pipes and doodad widgets around the room. Even the Zigot people got zapped from the scene. Finally, I said let's look at the machines.

We started hiding parts of the machine and test rendering. Eventually, the only thing left were the feet. Yes, these tiny feet that are never seen but were rendered. Each of the feet, and there was six of them on the machine were 256K polys! When we found this, we knew who had done it. It was the boss' younger brother who worked there at one time and had built the machines in 3d Studio. These feet were beautifully round and gorgeous, but not what we needed.

Dan deleted these invisible feet and setup the render for the day. The job completed in about 4 hours, much faster than the render estimate time actually said before. Once each image was rendered, they were sent over to a //Fast AG editing deck where they were recorded to video, frame by frame.

That's my 256k poly story.

[pware]

Sketchup has the very obvious and powerful attraction of being easy to learn and use - well one heck of a lot easier than Blender. Throw in a library of buildings, structures, objects, even feet, in an apparently vast online warehouse and you don't even have to create anything yourself. I am not complaining. I have had a copy of Blender installed on my various systems now for several years and I keep it up to date. But I have never used it - it seems so complicated (and even more complicated with each update) and I always have so little time. I periodically fire it up, take a look at the interface and decide "not today". I suspect that most others here in the forums are the same. I add that apart from experiments in the very early days of Sketchup (pre-Trainz) I do not use it and have never used it to create 3D models for Trainz.

I have a few Sketchup created assets installed in Trainz. I usually discover that fact after using them in a Route but provided I limit their use to just individual instances close to the track then they have no real affect on system performance. I add that the Sketchup trumpet is not one of the select few.

To get to the point, software tools that once required a Masters in Computer Science (or perhaps even a Ph.D) when they first appeared eventually become within the capabilities of mere mortals. The interface becomes easier to use and faster to learn, the technology (CPU, GPU, storage, comms, etc) become faster and cheaper, algorithms become much better at handling complex operations, etc. While Sketchup has been around for quite a while now, I suspect that it, or a similar competitor, will eventually overcome the drawbacks of using Sketchup models in gaming and simulation systems where draw and poly counts, LOD, etc are critical factors.

"Proper" 3D programs, like Blender, will also evolve to become easier to use, much easier I hope. I look forward to the day when I can say "Blender, render me a TRS28 friendly version of the 'Riverview Hotel, Balmain, Sydney' with LODs, PBR textures and full night mode. Add in an ambient Friday night pub crowd sound, but one that fades out over 100m. Oh and could I have it by 3pm this afternoon".

My thoughts.

[PWillard]

Blender has improved immensely since the 2.7 Days. Much more *usable*. Anyone still using 2.79 hates their life. ;-P

[pcas1986]

Blender has improved immensely since the 2.7 Days. Much more *usable*. Anyone still using 2.79 hates their life. ;-P

I've liked all the Blender versions since 2.49b but the later versions make it much easier to manage a multi LODed model such as a loco. The only thing I can't master is getting window colours that suit me and, more particularly, my failing eyesight. In any case, Blender is easily the best software tool I've ever used. Substance Painter would come a close second because it addresses all the issues I've had with texturing over the years. No wonder Adobe snaffled it up.

But, getting back to the original topic, I doubt if your average Trainz user would understand the "loading" statement mentioned in the the original post. I don't. Draw calls I can understand, mostly, but again your average user probably wouldn't.

[Dinorius_Redundicus]

But, getting back to the original topic.

Yes, thanks, the original topic .

Paul, post #8, has a simple equation at the bottom which coverts the dubious "load from textures" figure into an actual number of textures. That, plus triangle count, are at least unambiguous properties on which to judge an asset. I really can't understand why ModellerMJ didn't simply list triangle and texture counts in the first place.




.

[H222]

Unfortunately, Sketchup's biggest strength is its biggest weakness: It's so easy. I have exported landmarks of the city I'm building into Trainz where it will only be used literally once (and modified some textures to look and perform better) but man, so much of the stuff exported into trainz is just terrible for performance. It's not limited to sketchup - I loaded some new SAP loads onto a train the other day and my computer's frames halved. Realised the loads were about 140k polys each, with no LOD - 2 per wagon and I was rendering in an extra 10 million polys by loading that train.

Stuff not built for Trainz is rarely optimised for Trainz. LODs matter.