Mesh Editing / Optimization Questions

[GregBurch]

I'm in the process of trying to reduce polygons on a mesh before converting it to .msh form. For reasons irrelevant to these questions, the particular "polygon hunt" I'm on right now has to be done manually and is very tedious: I have to zoom WAAAAY into the part I'm working on and delete points manually.

So here's question numero uno:

1. Some of the points defining polygons I'm deleting are VERY hard to get to -- they're so close to and intwined among other points that it's difficult to "reach" them. I can get and delete SOME but not all the points that define a specific polygon, which makes the polygon, as such, "go away." This leaves some "free" points floating in the mesh. The question is this: Do these "free" points add to the rendering load in Orbiter? In other words, is it just polygons that put a load on the rendering, or am I doing no good by not deleting every single point that originally defined the polygon?

Here's question numero two-o

2. The second question has to do with textures. I've applied a texture to a mesh element. Then, as part of my optimization process, I'm deleting polygons on that subpart that aren't visible after that element is assembled into the whole mesh, but before export and conversion. What does this do to the UV coordinates? Will they be skewed when the mesh is converted to .msh and rendered in Orbiter? I THINK the answer is "no" based on previous experience, but am curious if anyone knows the answer based on knowledge of the actual mechanics of how Orbiter renders .msh files.

Any help on these questions will be much appreciated, as I'm putting a LOT of effort into mesh optimization that I don't want to be watsed.

 

[Coolhand]

1, i think this is a good example of why you should optimise as you go... extra orphaned verts do take up space in memory and should always be removed, whether orphaned verts are included in the .msh file i have no idea, they might be cleaned out as you export. or not.

2, this has nothing to do with orbiter itself, at least nothing thats unique to the .msh format. .msh (and pretty much every other 3d format)saves every face along with it's UV mapping coordinates, so removing say, one face from a cube will not affect it's neighbours since all their coordinates are linked to those faces.

moving vertexes around and merging faces and things like that will screw up UV coordinates unless you have some kind of "preserve UV" mode and even then that will only go so far but thats not what you're asking anyway

 

[GregBurch]

1, i think this is a good example of why you should optimise as you go... extra orphaned verts do take up space in memory and should always be removed, whether orphaned verts are included in the .msh file i have no idea, they might be cleaned out as you export. or not.

Amen, brother! I am a sinner and this congregation has helped me see the light on optimization. My early releases were monstrosities of excess polygons, and I still fall far short of what I ought to be able to do, but you definitely have hit the nail on the head about optimizing as you go. Optimization has to be a value you apply at every step of the process -- you have to think about what can and can't be seen, what's a needed detail and what isn't, as you make each part. I tend to build in modules or components now, and this aids that process of incorporating optimization into each step of the construction.

I would be curious to know what happens to orphan vertices when a 3ds file is imported into .msh, if anyone knows.

2, this has nothing to do with orbiter itself, at least nothing thats unique to the .msh format. .msh (and pretty much every other 3d format)saves every face along with it's UV mapping coordinates, so removing say, one face from a cube will not affect it's neighbours since all their coordinates are linked to those faces.

Excellent! So I AM doing good by chopping invisible polygons on a mesh after texturing.

 

[ar81]

UV coordinates are attached to vertices.
If you delete a vertex, no UV coordinate will remain for that.

When modelling for games, it is better to add details using a high detail texture instead of using polygons.

Also, it is better to use portions of a single big texture than many single small textures. Delta Glider and Shuttle fleet use that approach.

 

[Coolhand]

greg, it totally depends on your approach to texturing, if you're slapping tiled textures everywhere then it doesn't matter, the approach i usually take and what i did for the ravenstar is to have larger maps with lots of parts on it which are then precisely arranged in texture sheets, this is a common approach for small to medium vehicles. you'd definately want to optimise first then unwrap if you take this approach since you'll have to re-arrange your texture sheet/uvunwrapping to maximise the use of your textures - i don't like wasting space in my textures.

Generally you'd be better off using larger maps these days for vehicles, since most graphics cards have enough memory to handle it and you can have more variety in your maps, you can bake in lighting effects and so on, things that you just can't do with tiles since every situation that tile is used will be different. for large ships and structures however you'd be better off using a crafty system of tiles to maximise your texel coverage since the size of the maps you'd need to give adequate coverage would quickly get out of hand - so you could for example get close to the airlock without the surrounding texture looking like a mess of pixels.. Sometimes an efficient and good looking model might use a combination of the two, so you'd have a larger texture for your cabin with all your lighting baked in, and for example repeating trusswork or something you might as well use tiles and you could have a repeating lighting solution that might look nice and save a lot of memory with the repeating tile.

 

[Scarecrovv]

Something I noticed with the nVidia DDS plugin for Photoshop is that it generates MIPmaps that are then built into the file. This means you can have pretty large texture files for up-close viewing because it switches to the lower res ones when the model is further away. The question is, does Orbiter use them?

Crow

 

[n0mad23]

I'm under the impression that orphaned vertices remain in the mesh when exported. I'm constantly having Mesh Wizard inform me that it's removed hundreds of the buggers when I use it for optimizing.

Your pilots are so beautiful, Greg, that I'm curious about the polygon count for your characters. Are they as high as I imagine, or have you figured out some sort of trick here?

 

[GregBurch]

Your pilots are so beautiful, Greg, that I'm curious about the polygon count for your characters. Are they as high as I imagine, or have you figured out some sort of trick here?

There are definitely tricks. One is that I developed a process that insures that the Poser models are imported into Animator in a way that allows all the various pieces to be treated as separate meshes. Among other things, I optimize different parts of the people more or less, depending on how they will be viewed. Also, we primates are very attuned to faces, so I optimize the faces the least, but I trim as many invisible polygons there as possible (above the hairline, for instance), and almost always have the figures wearing headphones, so I can delete the hugely poly-intensive mesh of the ears, and often delete the equally-detailed eye areas by having them wear some VR glasses. :lol:

Even with all that, though, an average Burchismo copilot is probably c. 10-20k polygons.

When I get the time to finish it, I think you'll be pleased by the higher-poly version of the latest addon I'm working on. I've developed some new techniques for facial texturing I haven't used before and the copilot is turning out pretty well. But she's a poly pig -- something like c. 30k polys

 

[Urwumpe]

Can't you replace the crew meshes also by a FPS quality figure? I think these use only around 1500 polygons on the more luxurious versions, by relying more on the normals... 10K is a lot of wood.

 

[Scarecrovv]

20K for a pilot!!? I think I just had the horrors!

You want to be looking at 2-3K max really for realtime and really much less if it's only a pilot and part of a much bigger whole - maybe 800-1000 polys.

The trick is to let the textures do the work, not the mesh - but again keep them a sensible size too - like no bigger than 512x512 and use as few as possible.

Take a look at some game modelling sites for tips on detailing without detailing. One of the best is:

http://www.game-artist.net/forums/

Also the CGTalk forums have a WiP game art forum that's worth a look.

http://forums.cgsociety.org/

 

[tl8]

Even with all that, though, an average Burchismo copilot is probably c. 10-20k polygons.

This is already used

Scarecrow and Urwumpe, so if it already works well one your pc 30k isn't a very big step up.

 

[Scarecrovv]

To be fair I've just had a look at the LST Burchismo vehicle (which is a great addon btw) in Maya and it's totalling at around 60,000 polys. Considering that that is the high level of detail version and, on the whole it'll be the only thing onscreen, that really isn't too bad. You wouldn't want a fleet of them though

Crow

 

[n0mad23]

Headphones and VR glasses are excellent 'tricks' to be sure! I've been pondering this one a lot as I prepare to release the alpha of our Tortoise Class Lander. I just can't imagine having a working craft without visible characters inside the thing!

I'm afraid that what I'll end up using will suffice, but it will certainly be a "don't look too closely" at the crew. Not nearly as ugly as the Dragonfly characters, but no where in the same league as your Poser models.

I'm looking forward to seeing your latest facial texturing, and I continue to look to your work to inform my own.

Thanks Greg.