Entourage (LTC Luxury Personal Conveyance)

[Deus Siddis]

There were some visible artifacts, though; I managed to get rid of some in Gimp, and I put a neutral background and some padding. Should work a lot better.
http://wcjunction.com/temp_images/derivative_normal.png

The artifacts might be from blender 2.46's mesh to mesh normal baker and that being my first attept at this I guess I didn't notice them.

Just curious, why did you blur it?

The triangles, however.... I would say there are inverted normals all over the place in that mesh. That's the only thing I can think of. If you have the mesh in Blender, Ctrl-N attempts to fix normals globally; doesn't always work, tho.

Nope, there is nothing wrong with the normals, I always look for inverted normals while I am working and have learned what operations create them. And just to be sure I double checked the mesh again, it is clean.

If there are inverted normals then they must have been a product of the export process, perhaps mesher.

And by the sharpness of the triangles I would assume they use flat shading. Flat shading is terrible in terms of performance. One thing to do with all meshes, universally, is A to select all, then W->SetSmooth.
Now, where the mystery gets thicker is, why would the problem show up only when a normal map is put in?

Nope I never export flat shaded meshes and I don't even work with them- I reflexively smooth shade a primitive as soon as I add it. I use separate meshes to create smooth groups when I need to and normal mapping takes it the wrest of the way.

It sort of suggests that the mesh was exported with a Double-Sided attribute, which would hide the fact that normals were inverted, but which is even worse than flat-shading, performance-wise.

.OBJ files support double sided faces? That I didn't know, I will make sure to turn that off before export next time. But that still doesn't explain the problem with tangent space normal maps and the VS engine.

[chuck_starchaser]

There were some visible artifacts, though; I managed to get rid of some in Gimp, and I put a neutral background and some padding. Should work a lot better.
http://wcjunction.com/temp_images/derivative_normal.png

The artifacts might be from blender 2.46's mesh to mesh normal baker and that being my first attept at this I guess I didn't notice them.

Just curious, why did you blur it?

I didn't. I only blurred the background.
That's to try and get the surrounding background to match the colors of the islands it surrounds as closely as possible.
But I think you used margin, anyways. But margin is not good enough: First of all, if you use a margin of 4 pixels it's only good until the 2nd LOD. If you use 8, it's only good to the third LOD. Secondly, most of the artifacts that normal baking produces happen around the edges of islands, and then margin extends those very artifacts.
I use thick margins, but only because they shorten the number of needed blur passes

Nope, there is nothing wrong with the normals, I always look for inverted normals while I am working and have learned what operations create them. And just to be sure I double checked the mesh again, it is clean.

Hmmm... Okay...

If there are inverted normals then they must have been a product of the export process, perhaps mesher.

I don't think so, although, I've always used the old mesher.

But that still doesn't explain the problem with tangent space normal maps and the VS engine.

Wait! I think I know what the problem is: The islands are not oriented so that the front of the ship is UP in the texture; are they?
But this would produce smoother artifacts than that...
Did you check the *vertex normals*? Turn off Normals, and turn on Vertex Normals. Vertex Normals are the ones that *really* matter, by the way; the gpu doesn't know a face normal from a hole in the ground.
Vertex normals get screwed up royally when you rotate meshes in object mode; or if you scale them anisotropically. If you do such things in Object mode, you have to, eventually, hit Ctrl-A and Apply the transformations to the mesh.

And if none of this works, then we're in real trouble.

EDIT: I'm thinking, could this be an issue of de-synchronization between mesher and engine versions? The newest mesher version from Klauss' branch has tangents, but the engine in TRUNK doesn't support them yet, I don't think.

EDIT2:

.OBJ files support double sided faces? That I didn't know, I will make sure to turn that off before export next time. But that still doesn't explain the problem with tangent space normal maps and the VS engine.

Frankly, I don't know if .obj's support double sided; I imagine so, because gpu's do. In any case, the time to turn Double Sided off is not just before export, but from the very start. I don't know why Blender has that evil feature on by default; but you want to avoid it like the plague.

[Deus Siddis]

I didn't. I only blurred the background.
That's to try and get the surrounding background to match the colors of the islands it surrounds as closely as possible.
But I think you used margin, anyways. But margin is not good enough: First of all, if you use a margin of 4 pixels it's only good until the 2nd LOD. If you use 8, it's only good to the third LOD.

Good thing I used 16 then.

Secondly, most of the artifacts that normal baking produces happen around the edges of islands, and then margin extends those very artifacts. I use thick margins, but only because they shorten the number of needed blur passes

Yeah, I noticed that. Funny thing that blender bakes the backgrounds black for normal maps by default.

Wait! I think I know what the problem is: The islands are not oriented so that the front of the ship is UP in the texture; are they?

Well I don't know why that should make a difference, but it doesn't-- even though a few small islands are oriented not front to top, some of the ones that are showing the triangular artifacts in pyramid's derivative artifact screenshot are.

However, I think pyramid did say the ship was oriented backwards or was rotated 90 degrees or something when under the VS coordinate system. I don't know if that would make a difference though.

But this would produce smoother artifacts than that...
Did you check the *vertex normals*?
Vertex normals get screwed up royally when you rotate meshes in object mode; or if you scale them anisotropically. If you do such things in Object mode, you have to, eventually, hit Ctrl-A and Apply the transformations to the mesh.

No I had not before, but I just went back now and checked the vertex normals and they were all fine. I always apply scale/rotate to an object after those object level adjustments are complete.

And if none of this works, then we're in real trouble.

(Deus straps on a helmet, pisses his environment suit) Damn.

[pyramid]

Vertex normals get screwed up royally when you rotate meshes in object mode; or if you scale them anisotropically. If you do such things in Object mode, you have to, eventually, hit Ctrl-A and Apply the transformations to the mesh.

EDIT: I'm thinking, could this be an issue of de-synchronization between mesher and engine versions? The newest mesher version from Klauss' branch has tangents, but the engine in TRUNK doesn't support them yet, I don't think.

However, I think pyramid did say the ship was oriented backwards or was rotated 90 degrees or something when under the VS coordinate system. I don't know if that would make a difference though.

The mesher desynch should not be the problem. As far as I remember I did the meshing with the svn version as well as the test. But then again, I am working a lot on my win machine and could have used an older mesher, too. Will be more attent to that next time.

Actually I did rotate the mesh and for sure didn't apply anything to the mesh so this might be it.

I suggest, I'll check it out with the new normal map, the apply transform to mesh, and meshing and testing with both svn versions of mesher and vegastrike.

[chuck_starchaser]

Another question is, was the obj export from Blender done with or without normals? It should work either way, but just curious.
(I used to export without normals, religiously; but I believe exporting with normals is the preferred way now.)
I sent Klauss an email pointing him to this thread; maybe he'll have some idea what's going on.

[pyramid]

Usually I do export with normals and triangulation.

[chuck_starchaser]

I never use triangulation; --never even tried it. Try without it, see if that does the trick. There could be a bug with triangulation that neglects to fix the clock-wise ordering of the vertices or something along the lines.

EDIT:
This is what my export dialogue looks like, usually:



But you might want to export materials.
Also, I do click on high quality normals when I export a high poly version of the mesh for xNormal normalmap bakes.

[klauss]

The spec map just works fine.

The artifacts are probably not related to your texture, as I have seen them on almost any model I tried to add the bump map to, like in the case of the Derivative. It might be shader related, might be something else, I don't really know.

Btw, I was able to render a nice new hi resolution hud image with blender .
@chuck: appreciate your little tutorial.

It looks like a tesselation issue. Now that VS uses tangents, the unwrap must be tidy enough to work well with tangent-space normal maps. Usually this means using projections and LSCM as much as possible, and quads have to be tesselated always in the same direction. Ie, if you tesselate like this / you can't tesselate the adjacent quad like this \ , or you get those artifacts.

You can confirm this by computing your own tangent in the vertex shader (browse previous shader versions and you'll eventually find one that does it, copy that code to overwrite the tangent that comes in the vertex stream and see if it fixes the issue).

So sad I'm up to my eyeballs in work, because I would really like to figure this out. One of the hardest things of normal mapping is getting the tesselation right, and I'd like to be able to explain modellers what "right" means. Furthermore, the 4D tangents implemented in VS should already handle some tesselation artifacts - so, this is a bug that has to be squashed ASAP.

[chuck_starchaser]

Then the problem is indeed the exporting with triangulation, then, I'd say.
Automatic triangulation in Blender producess pretty much random \ and / 's.

Will quads work, Klauss? Because the simplest rule to state and follow would be "avoid triangles, and export
without triangulation". It is also the universal religion in modeling, nowadays, to avoid triangles at any cost.

EDIT: There's even a popular technique for switching from one tiling density to another that avoids triangles...



...and thus subsurf's well:

[Deus Siddis]

quads have to be tesselated always in the same direction. Ie, if you tesselate like this / you can't tesselate the adjacent quad like this \ , or you get those artifacts.

Well I didn't know if VS supported quads so I triangulated before exporting using blender's triangulation, which tends to use mirrored triangulation patterns (which can be better for pure gouraud shading imo) more often than the kind you describe.

So sad I'm up to my eyeballs in work, because I would really like to figure this out. One of the hardest things of normal mapping is getting the tesselation right, and I'd like to be able to explain modellers what "right" means. Furthermore, the 4D tangents implemented in VS should already handle some tesselation artifacts - so, this is a bug that has to be squashed ASAP.

What I don't understand is why blender has no problems whatsoever with any of this when it renders the model using the tangent space normal map?

Is this finicky-ness just a limitation of realtime tangent normal mapping or is this what you meant needs to be fixed on the code side?

[chuck_starchaser]

Well, Klauss just said that there are limitations/bugs in the present tangent code.

In any case, VS definitely supports quads. No need to triangulate; and in fact the whole world is trying to avoid triangulation at any cost these days. So, I'd say, first thing to do is re-export the mesh with quads only preferably; or with the minimum number of triangles possible, and see if that solves the problem.

[Deus Siddis]

Will quads work, Klauss? Because the simplest rule to state and follow would be "avoid triangles, and export without triangulation". It is also the universal religion in modeling, nowadays, to avoid triangles at any cost.

Well I created parts of the realtime model using subsurf, which creates non-planar quads that I thought had to be triangulated in blender anyway. So either way this mesh should have to use some triangles I would think.

EDIT: There's even a popular technique for switching from one tiling density to another that avoids triangles...

...and thus subsurf's well:

Yeah, I have done stuff like that to get around subsurf artifacts, it does a good job.

[Deus Siddis]

Well, Klauss just said that there are limitations/bugs in the present tangent code.

But is the triangulation pattern issue one of these limitations/bugs or is it something that will need to be worked around by modelers from now on? That is the question I have.

In any case, VS definitely supports quads. No need to triangulate;

VS' universe uses more organic shapes in its concepts for its ships and stations, which is where subsurf modeling really shines. But this also produces nonplanar quads that have to be triangulated at some point, right?

and in fact the whole world is trying to avoid triangulation at any cost these days. So, I'd say, first thing to do is re-export the mesh with quads only preferably; or with the minimum number of triangles possible, and see if that solves the problem.

Are you sure about that? Because you have the same non-planar quads issues as soon as you have almost any mesh-deforming animation like those of vertex or bone animations in characters for the gazillion FPS or RPG games out there.

[chuck_starchaser]

But is the triangulation pattern issue one of these limitations/bugs or is it something that will need to be worked around by modelers from now on? That is the question I have.

Well, the particular bug with tangents and \|/|/|\|\ random subdivision I presume will be eventually addressed; but what I was trying to say there's no need to jump into the problem with both feet by needlessly triangulating.

VS' universe uses more organic shapes in its concepts for its ships and stations, which is where subsurf modeling really shines. But this also produces nonplanar quads that have to be triangulated at some point, right?

Well, yes and no. Yes in the sense that when you don't triangulate a quad, you don't know how it's going to shade eventually; so what some modelers do, like Brad Mick, he keeps two versions of the mesh: one triangulated and one not. However, I can say I've been exporting non-triangulated meshes and haven't run into any problems of triangles being visible in-game; but I don't know why.
I've been thinking of suggesting to the Blender devs adding a second dimension to the multi-res feature: Allowing users to have triangulated versions of multires levels whose sense of triangulation they can control; but I haven't got around to write the proposal yet.
In the meantime, a triangulated mesh can at best be considered an intermediary format. The original, "source code" mesh should be made of quads, because working with triangulated meshes is nigh impossible; and converting back from triangles to quads is a huge task.
And in any case, like I said, I've been trying to avoid triangles, and NOT using triangulation on export, and haven't had any problems; so I would advise avoiding triangles, period.
Non-planar quads are in fact the most common, as even the limits of precision of floating point vertex coordinates nearly precludes the possibility of perfectly planar quads. Having said that, highly non-planar quads can be, and should be avoided.

and in fact the whole world is trying to avoid triangulation at any cost these days. So, I'd say, first thing to do is re-export the mesh with quads only preferably; or with the minimum number of triangles possible, and see if that solves the problem.

Are you sure about that? Because you have the same non-planar quads issues as soon as you have almost any mesh-deforming animation like those of vertex or bone animations in characters for the gazillion FPS or RPG games out there.

Here's a good website about mesh tips, techniques and philosophies:
http://www.subdivisionmodeling.com/
You'll NEVER find those guys advocating a single triangle.

Let me cook up an example in Blender; hold on...

[chuck_starchaser]

Here we go:
You're trying to make an air-intake, say and you end up with two crooked quads (highlighted):



Instead, you can extrude the whole intake up, which forms only quads, then rotate the top down to tilt it, then shear the bottom edge lines outwards, and move the back edge forward just a little bit, and you end up with:



in which all quads are flat, as you can see from this perspective:



and subsurfs well, too...

[Deus Siddis]

Well, yes and no. Yes in the sense that when you don't triangulate a quad, you don't know how it's going to shade eventually; so what some modelers do, like Brad Mick, he keeps two versions of the mesh: one triangulated and one not. However, I can say I've been exporting non-triangulated meshes and haven't run into any problems of triangles being visible in-game; but I don't know why.

In the meantime, a triangulated mesh can at best be considered an intermediary format. The original, "source code" mesh should be made of quads, because working with triangulated meshes is nigh impossible; and converting back from triangles to quads is a huge task.

My source files are never triangulated, only exports are when I think that is all the destination engine can handle.

But as a side note I will say that Blender's "Join Triangles" tool works really well, in my experience, but that maybe changes for complicated meshes that are formed by combining various separate primitives and such via boolean operations or manual welding.

And in any case, like I said, I've been trying to avoid triangles, and NOT using triangulation on export, and haven't had any problems; so I would advise avoiding triangles, period.
Non-planar quads are in fact the most common, as even the limits of precision of floating point vertex coordinates nearly precludes the possibility of perfectly planar quads.

Alright then, I will export quads from now on.

Having said that, highly non-planar quads can be, and should be avoided.

Here's a good website about mesh tips, techniques and philosophies:
http://www.subdivisionmodeling.com/
You'll NEVER find those guys advocating a single triangle.

Let me cook up an example in Blender; hold on...

Okay I see what you are doing.

Though I meant more the result of a subsurf modifier created non-planar quads, not that the starting mesh was too hard to model using planar faces. But like I said I will try to use very few triangles from now on and not be so concerned with perfectly planar quads, so it matters not.

[Fendorin]

hello

i see a kind of problem on my computer ( the svn game)

on the last commited ship i have this kind of thing ( i see that on the §Entourage and on the Vigilance:



it"s look like a scale problem between the model-ship and the thruster

thank

[loki1950]

it"s look like a scale problem between the model-ship and the thruster

Looks like it just an edit of it's entry in units.csv

Enjoy the Choice

[pyramid]

I'd like to do the correct placement of engine thruster exhausts in blender via the mount helpers. But strange things are happening. While I have the textures loaded correctly (render works) when I switch on the viewport shading "Textured" I see only a pink shape (with no shading at all). What's happening?

[chuck_starchaser]

Pink means the texture is NOT loaded. There can be many reasons. Maybe the path is not right. Maybe you're trying to load a DDS texture renamed to .png which Blender doesn't understand. Maybe the texture is named but the name isn't even associated with a texture. Click on the leopard skin icon and see if the texture index name is there, and there is a texture specified for it. If not, you can click on the drop-down menu and go to Image File or whatever it was, near the bottom of the drop-down. In the Input tab it should say UV; in the output tab each texture needs to be configured differently (Col, Mix for diffuse, for instance.).

[pyramid]

Pink means the texture is NOT loaded.

But it shows in the preview and renders fine. How can that be when it's not loaded?

There can be many reasons. Maybe the path is not right.

Nope.

Maybe you're trying to load a DDS texture renamed to .png which Blender doesn't understand.

It's a png.

Maybe the texture is named but the name isn't even associated with a texture. Click on the leopard skin icon and see if the texture index name is there, and there is a texture specified for it. If not, you can click on the drop-down menu and go to Image File or whatever it was, near the bottom of the drop-down. In the Input tab it should say UV

Got that all correct.

In the output tab each texture needs to be configured differently (Col, Mix for diffuse, for instance.).

Is there any global setting that would prevent textures to show in the view but render them correctly?
The thing is that Entourage renders correctly in blender but just doesn't show the texture in the viewport.

Maybe a screen shot will help:


You can see the view settings, the viewport shading set to textured, the render window, the textured preview, the map input and texture.

[Fendorin]

I had exactly the same thing when i open the file you sent me (the archimedes for 23 turrets placement last week )

i don't know what is it i worked with the Solid mod and after wireframe and box and shading and then return to Texture mod and is was good maybe is just a internal problem i don't know i think you need o recreate the way to your files especially when is a sending files!!

EDIT: i m just under trying but is true i recreate the link of the ARCHIMED texture and is not working , normally when i export files the blend files are linked with the texture.png files maybe is that the mistakes? i don't know why the archimede files you send me had nothing in texture panel (calling Kd) and when i m render the "world background" is blue in setting but black on the rendering

when you worked on the Archimedes have you the texture??
because maybe is your blender was corrupt the files when you save it??
i m not a specialist but blender sometimes is instable!

[Fendorin]

@pyramid

i check again the files you send my and open my own files .....is the same setting :

BUT after trying over your files i open a Duelist files (work well i don't touch it since i did a screenshot posted in this forum) and: it was every time SHADING mod exept in boundy box ....

i think your files corrupt my blender...(maybe i m not specialist)

then i reinstal blender 2.47 and open again your archimedes files (the one you sendt me) and ....tadam.... blender made a lot of strange artifact itself see i just turning to 30degres nothing else:



i see a green squar (scale) mixed on with a arrow....etc
and the size of the path change to tiny and very big
all had nosense

i think your blender need to be reinstall and you need to remake your file at beginning....

and don't open again the files you made with your "old" version is a corruptor maybe......( i m not sure but try it is free (time is money but....))

[chuck_starchaser]

Uh.. wait... I must have been shit-face drunk..

The edit/object windows don't use the material textures setup.
They ignore that completely. That's ONLY for rendering.
For a texture to show in the edit or object window, you need to go to edit mode, press A to highlight all polygons, then in the UV Edit window you go to Image -> Load Image and select the texture file.

Sorry I misled you.

[pyramid]

OK. Gotcha! Now I can work again with the models

*EDIT*
When I have a shield mesh in the blender file, it normally obstructs the view of the vessel. Is there any good way to make it not be visible but still there in the file?

*EDIT2*
Never mind, I've found the layers