Page 2 of 2
Posted: Sun Jan 24, 2010 12:28 am
by Griff
i've just updated the oxp with a new version of the barrel that leaves the top and botom surfaces edges soft, this gets rid of the abrupt lighting change, i also sorted out the normal map so it mostly works ok, mostly because there does indeed seem to be something wrong with the map on the polygons that make up the bottom of the barrel - it's had to tell though, traders keep scooping up the pods whilst i'm sitting there watching them spin
Posted: Sun Jan 24, 2010 8:42 am
by Captain Berf
Griff wrote:i think the normal map problem is my fault, i need to invert the tones in some sections of the original texture before sending it through the photoshop plugin -basically on some faces the 'bumps' are 'dips' and the 'dips' are 'bumps' - at least i think that's what the problem is.
Perhaps I'm going blind, but sometimes my maps seemed inverted when rendered. Especially the 'metal sheeting' grids where the borders seem raised whether the source was inverted or not.
Just an observation from when I was running a bunch of test maps (through the GIMP plugin) to figure out normalmaps.
Posted: Sun Jan 24, 2010 10:40 am
by Eric Walch
Griff wrote: traders keep scooping up the pods whilst i'm sitting there watching them spin
type in the console:
Code: Select all
mission.runScreen({model: "your_role"})
This will generate a missionscreen in 1.74 with your spinning model at full size. (like I did with the dredger-shuttle a few messages back)
I now converted also the asteroids. Half of them contains still missing triangles. Maybe it is because Charlie's meshes were a mess to begin with.
Posted: Sun Jan 24, 2010 11:08 am
by Griff
Captain Berf wrote: Perhaps I'm going blind, but sometimes my maps seemed inverted when rendered. Especially the 'metal sheeting' grids where the borders seem raised whether the source was inverted or not.
Just an observation from when I was running a bunch of test maps (through the GIMP plugin) to figure out normalmaps.
No you're not going blind, this is indeed happening, to fix it you'll have to make a note of which surfaces on your model in oolite have their dips and bumps the wrong way around, then in GIMP go back to your source image you generate the bump map from, select the area in the image that has the wrong way around bumps & dips and invert its colours, then run it through the normal map plugin again, this should sort it out.
I only realised this recently so a lot of my early normalm mapped ships have this error.
When i make normalmaps i usually select the 'invert y' option in the plugin options and then to invert the source image in the areas that will map onto the underside, the back and the 'Starboard' side i think - (the polygons with their normals facing in the X + direction) of the model
Posted: Sun Jan 24, 2010 11:15 am
by DaddyHoggy
I've got a fantastic video I use in one of my lectures about "when normals go bad" - it's of a rotating Challenger 2 model which 50% of the time looks like it's been turned inside out - when I get back to work I'll host it somewhere and post a link here - it may help the uninitiated visually see the issue as it occurs.
Ahruman's explanation about back face culling was very good though!
Posted: Mon Jan 25, 2010 2:43 am
by Captain Berf
Ahhh.
Thanks Griff. Those results thoroughly confused me.
I had no idea that different regions could be interpreted differently.
[When normals go bad ... excellent]
Posted: Mon Jan 25, 2010 2:16 pm
by DaddyHoggy
For anybody who is trying to follow this discussion out of professional curiosity but isn't quite sure what's going on, then perhaps this video will help. This CR2 model was converted from one modelling system to another and, as you can see, the winding on the polygons went horribly wrong...
http://www.box.net/shared/cs0qydpd3k
It's rotating clockwise BTW, not that your brain will accept this after the first 10s or so!
Posted: Thu Jan 28, 2010 11:18 am
by ClymAngus
If you could actually get this to work for you, then you would have your shields.
Posted: Sat Jan 30, 2010 11:04 am
by Eric Walch
I had still problems with missing faces with half of my asteroids. When looking at the python script I noticed Ahruman added a selection in the script:
Code: Select all
# Specify winding mode. Winding determines which side of a triangle is out.
# If a model appears "inside-out" or has missing faces, you need to adjust this.
# 0: maintain original winding.
# 1: reverse winding.
# 2: select winding automatically for each face.
# 3: select winding automatically for each face, but buggily (the same
# behaviour as Oolite for old-style model files). You probably don't want
# this.
winding_mode = 2
After changing the winding_mode to '0', all my asteroids ended up correct without missing faces. All my obj files were generated by wingz.
Posted: Sat Jan 30, 2010 11:48 am
by ADCK
Eric Walch wrote:I had still problems with missing faces with half of my asteroids. When looking at the python script I noticed Ahruman added a selection in the script:
Code: Select all
# Specify winding mode. Winding determines which side of a triangle is out.
# If a model appears "inside-out" or has missing faces, you need to adjust this.
# 0: maintain original winding.
# 1: reverse winding.
# 2: select winding automatically for each face.
# 3: select winding automatically for each face, but buggily (the same
# behaviour as Oolite for old-style model files). You probably don't want
# this.
winding_mode = 2
After changing the winding_mode to '0', all my asteroids ended up correct without missing faces. All my obj files were generated by wingz.
Sounds like the same problem I'm having.
<Edit> Nevermind, changing it to 0 still hasn't fixed it for me
Posted: Sat May 22, 2010 3:05 pm
by JensAyton
Ahruman wrote:There seems to be a problem with tangent generation, which primarily affects normal-mapping shaders.
Came across this again today. After almost two whole seconds of thinking, I realised what the problem was: the basic concept of generating one tangent per vertex for a model with explicit normals does not make sense. The way the mesh code is organised, there is no easy fix for this.
This will probably not be fixed before MNSR.
So basically, you can’t usefully use normal mapping with a model that has explicit normals but no explicit tangents. There is currently no tool to generate correct explicit tangents.