[Enioch]

Greetings to all.

In the process of unwrapping and texturing ships for the Renegade Legion Mod, I have run into a brick wall. Not literally, of course. That would be silly. I meant it metaphorically.

I have decided to consult the Modding and Coding Deities of HLP, in the hope that I might regain my sanity.

Consider, dear readers, the following, crudely UVmapped, box-like thing:



It has been mirrored-X and its mirrored side UV map has been offset 1 square UV map 'area' to avoid the auto-merging PCS2 issue that leads to nasty seam effects. Areas have been marked green and red, so that the relation between 3d view and UV map view is clear.

This 'box' has been exported as .dae, imported into PCS2 without a hiccup and exported as .pof.

As a height map, I have created a light gray/black grid, that, when converted with the Photoshop NVIDIA plugin gives me a DXT5-nm file that simulates a 'checkerboard' of raised panels. See below:



"There's nothing wrong with that!" you might say.

There is.

If I turn the model just a bit, this happens:



And then, this:



In the immortal words of Mr. Spock:



Of course, I'm sure it makes logical sense. Somehow. Somewhere along the route, I have screwed up royally, but I'm not sure where.

Thus, I would like your opinions on the matter.

What am I doing wrong? How can I mirror a ship while getting rid of this nasty lighting effect? Give me RULES give me a GUIDELINE give me something in the line of "This appears only if you [insert case here]", so I can tailor my UVmapping to address the problem.

For all it's worth, I have a Geforce GTX 260M, running the latest drivers and I'm running my mod on the latest Nightly, with these flags:

-spec -glow -env -mipmap -nomotiondebris -noscalevid -missile_lighting -normal -3dshockwave -post_process -img2dds -no_vsync -cache_bitmaps -orbradar -rearm_timer -ballistic_gauge -ship_choice_3d -3dwarp -warp_flash -snd_preload -output_scripting  -ambient_factor 100 -no_emissive_light -spec_exp 16.7 -spec_point 0.6 -spec_static 0.9 -spec_tube 1 -bloom_intensity 150


Thank you for your time.

[The E]

Could you post the model, textures and tables here?

[Enioch]

Of course.



[attachment deleted by ninja]

[Spoon]

3 possible lighting related issues
The two mirrored pieces are not welded together
Smooth is not assigned properly
Model has not been reset x-form'd  (which may have a completely different name depending on the program you're using, or may not be there at all)


edit: and then I saw the pof that got posted before I posted

[Enioch]

Smooth is not assigned properly

Explain please.

The model has no smooth sides. None. Everything is "Set Solid" in Blender.

[Spoon]

I dont speak blender so I have no idea what means 
I only know that smooth (groups) does things with the lighting in freespace

[Angelus]

When UVing, avoid 90degree angles in one element.
Either, break ( or whatever it's called in Blender) all elements that are in 90deg to each other, in the UV editor or champfer the edges.
The latter has the downside that it increases polycount plus it make s UVing even more annoying.

[Enioch]

I dont speak blender so I have no idea what means 
I only know that smooth (groups) does things with the lighting in freespace

 
It means that nothing is smooth. There are no smoothgroups. All surfaces are 'solid' i.e. not smooth.

When UVing, avoid 90degree angles in one element.
Either, break ( or whatever it's called in Blender) all elements that are in 90deg to each other, in the UV editor or champfer the edges.

Whut.

You do realize that the problem lies somewhere in the mirroring, since it shows up in the central 'recess' where I have two mirrored, co-planar polygons? No 90 degree corner there...

[pecenipicek]

Enioch, you might also take a look at this joyful mess...

[chief1983]

I get deja vu every time I see a thread about normal maps on mirrored polygons.

[Enioch]

Enioch, you might also take a look at this joyful mess...

I did. Nothing came out of this, did it? zookeeper suddently could no longer reproduce the problem. And I skimmed through the discussion, without finding an explanation.

I get deja vu every time I see a thread about normal maps on mirrored polygons.

Well, if we get a clear answer that fixes the problem, there would be no more need for such threads [/irritated and already sorry for snapping]

[chief1983]

I thought there was another discussion of the issue with a solution in the forums somewhere.

[Water]

If I remember right, the linked discussion was mostly about wielded vertices affecting smoothing/normals rather than mirrored normals.

Three images
1st - cob - separate sub-object - uv's not offset. All looks good.

2nd - same again but uv's offset. Not so good.

3rd - dae - uv's offset didn't matter. Separate sub-objects didn't help.

First two were done with PCS2RC3d (Jan08) only because the latest version crashes during importation of the cob.
I also tested the cob with PCS2.1 (Jan09)



[attachment deleted by ninja]

[chief1983]

There are much more recent versions, if you have a model that crashes PCS2's most recent releases, please mention it in the FSO Tools forum.  Spicious or someone will probably take a look at it and see if there's anything wrong with PCS2's handling of it.  The Jan09 version is not the latest release by far.  Check the tools forum, specifically Spicious' signature if you can't find a link anywhere else.

[Water]

Using  dae with a proper High poly > Low poly baked map.

Short version: If you want to use photoshop derived normal maps on mirrored geometry use the obsolete COB format. (Edit: wrong answer. was only true for poor quality normal map)

[Enioch]

Using  dae with a proper High poly > Low poly baked map.

Short version: If you want to use photoshop derived normal maps on mirrored geometry use the obsolete COB format.

*Sigh* Oh dear. WHY? What's the difference? Why does it work with COB and not dae? Any ideas?

AND: Why a different sub-object? Is it necessary?

AND: Does COB support smoothgroups, or am I gonna get a balooney mess? I think I remember some issues on that point...

AND: What is different about baked and photoshop derived normal maps that makes such a difference?

Oh, and Water - THANKS A LOT. 

[Scooby_Doo]

Or just don't share the uvmap for the mesh sections :-)

or..... do uvmapping AFTER you've done the symmetry.

[Enioch]

Or just don't share the uvmap for the mesh sections :-)

What mesh sections?  Don't get what you're saying. Are you saying I shouldn't share UV space on any faces? That's the point of this thread. That's what I'm trying to do. I'm asking HOW to do it properly, and the answer is 'don't do it'?

or..... do uvmapping AFTER you've done the symmetry.

The whole point is to save UVmapping time and texture space. If I UVmap after the mirroring, I'll have to UVmap twice the faces.

[Water]

Cob and sub-objects were for testing. The format had a smoothing type called Faceted, maybe Dae treats it differently.

Simple solution don't mirror the central section. Re-unwrap that section as one piece.

The main difference, photoshop normal maps don't take any account of the underlying model's normals. Using High poly > Low poly baking, this info becomes part of the normal map.
If you want to get into Hi poly baking both Blender and xNormal are good choices.

If you look at the colours you'll notice on each poly they shift from top to bottom and also left to right. That's from the models normals. The whole model was smoothed. The less colourful parts had the smoothing controlled by edge support loops. It effectively made them look like they were set solid, while actually set smooth.

[Enioch]

That...isn't very convincing. How come this issue doesn't show up in mediavps and other models? Mediavps models have also made-in-photoshop noral maps, and yet they don't turn half black when the light catches them in a different angle. What's the difference?

By the way, the issue is not limited in the central section. The entire mirrored half of the model gets darkened. If the central part looks good and the 'outside' poly looks black, the model will still look weird.

Using High poly > Low poly baking, this info becomes part of the normal map.

Huh?

It doesn't show.

The normal map you posted has shifting colors, sure, but that's because, as you said, the entire model was smoothed. Thus, the 'baked' normal map tries to mimic the 'smoothing' and the normals of the surfaces shift.

That's all fine and dandy. But the 'edge-split' faces, the ones that are smoothed yet separated, in order to 'look' non-smooth look pretty standard to me (i.e. similar to a photoshop-generated normal map). How does the normal information in that map differ from the normal information in a photoshop-generated map? If the colors are the same, the normal information in the map should be the same as well.

Thanks again for the continuing feedback.