From My Basement To You, Fellow Graphicians

[darkblu]

ok, fellas, after spending some time on these forums i came to the conclusion that the following may actually be of some use to those of you striving to get their 3d assets in order.

it is one of my home-made testbed tools that i have been using for some time now to test this, tinker with that, and generally, waste my spare time. accidentally, it also can be very useful for inspecting mesh properties, particularly: normals orientation and length across the surface, and mesh appearance under phong shading - all that controllable in real-time, in both per-vertex and per-pixel flavors. it also shows mesh bounding boxes no questions asked, and demonstrates a simple view-frustum clipping algorithm in real time (using two cameras for the purpose), giving you a visual clue how your meshes would behave under frustum clipping.

the tool is ogl-based (doh), and runs on a bunch of platforms - osx (tested with ATI under ogl 1.4 and intel GMA under ogl 2.0), linux (tested with ati`s ogl 2.0 through 3.0) and cygwin (intel GMA under ogl 1.4). to build the tool you will need GLUT (across all platforms), GLEW (under linux and cygwin) and lib3ds (again, across the board).

the tool`s code is also not for the faint-hearted - it does certain things people with good manners would never, ever do, even under the privacy of their own showers. it is not expected to be liked, though, but to get certain job done. so, here, without further ado, right from darkblu`s dark, humid dungeons, i unleash upon you the

CODE
http://singularity.homeunix.net/ntsh-jass.html

* batteries not included.

to spare you some of the frustration in case you decided to actually try it out, here is a brief on the run-time controls:

"z", "Z": lift primary camera`s position along the Y axis
"x", "X": lower primary camera`s position along the Y axis
"a", "A": lift primary camera`s aim
"s", "S": lower primary camera`s aim
"q", "Q": halve primary camera`s orbiting radius (around Y)
"w", "W": double primary camera`s orbiting radius
<space>: toggle primary camera`s orbiting around y
<return>: take a snapshot of the framebuffer, saved in raw format in the current dir
"4", <numpad_left>: move secondary camera along -x
"6", <numpad_right>: move secondary camera along +x
"2", <numpad_down>: move secondary camera along -y
"8", <numpad_up>: move secondary camera along +y
"5", <numpad_center>: move secondary camera along -z
"0", <numpad_bottom>: move secondary camera along +z
"i", "I": switch main camera to using normal-direction-visualizer material, repeat for per-vertex version
"o", "O": switch main camera to using normal-length visualiser, repeat for per-vertex version
"p", "P": switch main camera to Blinn-Phong shading, repeat for per-vertex version
"`": toggle culling between CCW and CW (by default CW is culled, CCW is shown)
"-": halve secondary camera`s side extents
"+": double secondary camera`s side extents
".": save the currently view mesh set to native format in the current dir, under the name "out.mesh"

now, the tool handles two mesh formats:
(1) its native .mesh (text-based, just position + normal, indexed) - in both reading and writing, and
(2) .3ds - the famous 3d studio format, from the time when 3ds studio still had a standardized file format - as read-only.

whereas the native format handling is fairly bland, the 3ds handling comes in two flavors: simple and lib3ds-based. the difference being that the former does a quick-n-dirty handling of smoothing groups, while the lib3ds-based handling is quite sophisticated. as a matter of fact it is so sophisticated that it could take some heavier meshes several minutes for read-in and pre-processing (i do a topology optimization pass on top of what lib3ds provides). generally, if you dont have the patience to open some mind-boggling-complex 3ds file on your desktop, ask your overclocker friends to use the tool, open the file and save it to native mesh format. needless to say the native-format version would load way faster.

well, that is about all there is to it. hopefully somebody here would find it useful.
cheers.

ps: just to make it clear: the package on that page contains _sources_only_ - you will need to build it for your platform using the Makefile, or the xcode project, in case you run osx; the Makefile can be used under osx too, but might prove to be too complicated in comparison.

 

[torpor]

Wow, this is great! I was looking for something like this myself and gave up trying to figure out how to use Blender to do it .. Thanks!

 

[Butterman]

Hehe, I can't help but think I'm one of the reasons for this .

I like the fact that you haven't got clean code and admit to it, I hate idiots who go on about correct practices all day long, they're usually the guys who get absolutely nothing done.

As long as it's commented it's good in my books

 

[darkblu]

Wow, this is great! I was looking for something like this myself and gave up trying to figure out how to use Blender to do it .. Thanks!

np, glad to be of help.

Hehe, I cant help but think I am one of the reasons for this .

I like the fact that you havent got clean code and admit to it, I hate idiots who go on about correct practices all day long, they are usually the guys who get absolutely nothing done.

As long as it is commented it is good in my books

duh, of course you are one the reasons : )

and yes, some of that code is heart-breaking - i will shed a tear when one day gnu change their std::map implementation and that custom container of mine built on abusing the internals of the current std::map crashes and burns, bringing down entire civilizations with itself :evil

 

[warmi]

Depth based sorting is not that useful on SGX class of hardware - frankly, it is rather wasteful except for the final transparency sort, which should only be applied to transparent materials.

I would suggest using some sort of custom hashkey sorting which would allow people to create their own hashkey based on materials/shaders/transparency etc ..

 

[darkblu]

Depth based sorting is not that useful on SGX class of hardware - frankly, it is rather wasteful except for the final transparency sort, which should only be applied to transparent materials.

I would suggest using some sort of custom hashkey sorting which would allow people to create their own hashkey based on materials/shaders/transparency etc ..

while i would agree with you in principle, in practice depth-based is what you need under most conditions and most configurations (SGX being an apparent exception), _unless_ you have serious issues with your assets - i.e. scene content leading to asset eviction from local memory, etc. anyhow, ntsh-jass codebase, as it is now, is unsuitable for either es1 (uses shaders - arb/ati and glsl in a different banch) or es2 (uses certain fixed-pipe facilites), so this whole argument is hypothetical.

truth be told, though, i do plan to add a custom hash-key sorting group-node to the graph (that is what the manual-sorting-order group type does anyway, the key is just opaque), so consider this issue ultimately covered.

 

[MadDog]

On systems with a zbuffer (or similar like PVR) I've never seen z sorting to give any speed up. I've been told by many IHV's that doing this will speed it up and in theory this is correct. But I've never seen it work, and I've tried it out on a few games I've worked on. I have seen it slow stuff down as it messes with texture changes and uniform uploads, in that it can cause more of these.

Always pre sort by texture, can be done off line and gives a big win and is CPU free.

 

[darkblu]

On systems with a zbuffer (or similar like PVR) I've never seen z sorting to give any speed up. I've been told by many IHV's that doing this will speed it up and in theory this is correct. But I've never seen it work, and I've tried it out on a few games I've worked on. I have seen it slow stuff down as it messes with texture changes and uniform uploads, in that it can cause more of these.

Always pre sort by texture, can be done off line and gives a big win and is CPU free.

depth-sorting of opaque meshes is a fill-rate optimizing technique, and as such it helps whenever fillrate is your bottleneck. if your bottleneck is elsewhere saving on fillrate will not help you.

IHVs are usually right, though, as their concern is with the performance of their GPUs under the optimal-case scenario - they dont really care if your game has problems elsewhere.

as about GPU-local assets spilling - this is something which should be avoided, or at least its impact should be minimised if spilling is unavoidable, and this is something addressable at scene design stage. saying that fillrate optimization is useless due to the danger of assets spilling is like saying good car airdynamics does not matter as pickup trucks cannot go that fast anyway.

you do realize that if asset-spilling was all that mattered in real-time graphics, and fillrate was a non-issue, then architectures like PVR would not be alive today, right?

 

[darkblu]

on the ever-recurring topic of smoothing groups, normals and how the heck do we get those right:

here is a little something that may (or may not) help you, smoothing-group fighters, to get the upper hand in the fight: a glsl shader pair that generates normals (and, accidentally, the whole tangent-space basis needed for tangential normal mapping) on the fly.

CODE
http://singularity.homeunix.net/testbed_pt.tgz


what you will find in there is:

* a small testbed/demo app that builds a mesh and applies the above-mentioned shaders; this time i have even included a pre-built linux version (you will need libGLEW.so.1.5, libglut.so.3 and libGLU.so.1), but osx and cygwin users will have to build their own binaries, like grown-ups do (using the supplied Makefile).
* a pair of well-commend glsl shaders, with a bunch of conditional-compile control points to tinker with:

in phong_bump_tang.glslv:
CODE

#if 1 // orthographic projection


i suggest you keep that one the way it is, as the demo does actually do orthographic projection, and in a somewhat minimal way at that.

in phong_bump_tang.glslf
CODE

#if 1 // compute tangent and bi-tangent from texcoords
#if 0 // compose TBN taking into account the mesh-supplied normals
#if 1 // invert x and y on the bump map
#if 0 // apply diffuse map with alpha


the first one you definitely need if you want correct TBN composition; if you plan to do just phong without normal mapping then you can flip it off (but you will also have to further edit the fragment shader on your own to do plain phong).

the second one is there for visual comparison to when the mesh does carry its correct normals (the demo mesh does) - flip that flag to see how much faceting the on-the-fly normal generation does in comparison to proper mesh normals.

third one is needed to make the demo-supplied normal map work with the TBN computation employed; you can leave it on (or flip it just for kicks).

forth one activates the use of the demo diffuse map. if that is missing, a synthetic diffuse map is generated; apropos, makes for a somewhat cool effect when used with the on-the-fly normal generation.

well, that's about it. hope that helps you in the good fight for normal correctness.

*looks at Butterman*

 

[darkblu]

just a heads-up to let you (the hypothetical you, not anybody in particular) know that NTSH-JASS has a GLSL fork now (no assembly shaders whatsoever - isn't that great, Timmy?).

place is same as before - http://singularity.homeunix.net/ntsh-jass.html

Along with other things, I've rewritten the (mesh) attribute-buffer abstract too. Now there are two versions - a lockless one (relies on user-space-mappable VBOs) and a lock-requiring one (no mapping needed). Remember to always treat your buffer objects with care, as they are your grunts out in the field.

 

[Username]

They should take a lesson from this being a good reason to gravedig.