A second type of "bumpmapping" possible but not yet discovered. (?)

[Legacy_MerricksDad]

               

Since your models are compiled, and there is no TXI, can I assume that a compiled model grabs the TXI information and puts it in the model? I saw no TXI files in the download earlier either.

               
               

               
            

[Legacy_MerricksDad]

               

Here is my group shot showing the failure in the worm envmapping. I think my video card does not handle env mapping + texture animation at the same time. I have similar problems with my own moving water when there are more than one layer.

 

 

This one shows the worm thing after I disable character env mapping, and then turn it back on. All envmapping on non-creatures is removed, but now I can see the base texture on the worm thing.

 

               
               

               
            

[Legacy_MerricksDad]

               

I tried a few things and am loving it.

 

• inverted base texture


• set the spherical env map to grayscale without reducing color count (colorize 0 saturation)


• copied only the texture color from the grayscale spherical map to the purple and brown images, without changing the alpha channel

The one on the left is spectacular now, and shows more play as it rotates. The one on the right seems a bit dark. The teapot looks like the texture Z coordinates are upside down, and no change on the worm thing not working for me.

 

Edit:

 

The only thing I can get it to do is play to the environment direction, not the light source. As it rotates, there is no play of the light from dark to light with or without all the env map textures set to spherical textures. It only plays when you rotate the camera, and only represents the spherical layout of the env map. I've tried putting differnet light sources in the area, but I can't change the direction of the environment light, as it seems to be set in a global direction.

 

Still, this is pretty neat, especially if you do those things I listed above. That one on the left REALLY pops. But really, this isn't much different than I was going for with the shiny skinned drow I did a few years ago. This is a bit further along, and would be great used on characters, but the lighting will only shine for the camera direction, or with the case of your off-center env-map, would look more bright when viewed slightly isometric.

 

I can use this '>

 

It would be far more beneficial if you could mix transparent and env mapped meshes on the same model, rather than setting the reflection entry in the placeables 2da and have it capture both textures on a single model.

               
               

               
            

[Legacy_OldTimeRadio]

               

After poking this a bit more, some guesses which reference the lighting of the sphere and the plane.

 

Lighting:

Okay, I believe I was incorrect in my response to Zwerkules, who suggested the screenshot with the purple light-painted sphere might be the result of an additive blending TXI.  It looks to be simple interaction between the alpha channel on the image and light source.  It makes sense: If the surface has X lighting value, when a light's exposed to it it'll have X + whatever value it gained from the light and in the color of the light.  If the surface value is very low, low enough to be quite transparent, the light appears to give it a surface or "paint" it.  This effect is the same whether or not the RGB channels are the same or different, as in a normal image.  The effect is more pronounced in darker areas but still present in normal lighting, though the texture is lit up quite a bit more by the existing light.  

 

Why does the light look so good?

The lighting (for at least the light generated by adding one in placeables.2da) is very nice and smooth and I suspect this is why the plane looks so nice, too: If I have the light at the top of a plane (that isn't too big), the bottom won't be as well-lit as the top.  And a smooth gradation of light that's reflecting off the alpha in the above paragraph gives the sort-of illusion of a lit 3D surface.

 

What's happening in the texture?

Still not 100% sure, but I have a guess: The whites and blacks in the alpha shouldn't be absolute white or black values, fit into some range NWN likes (I have yet to determine that, maybe the Omnibus can help) and the whole texture has to be in it.  No "holes".  If it's a texture with different RGB channels (i.e. a regular color one), there probably wouldn't be a problem with having pure white spots in alpha to let certain features be opaque- but they wouldn't benefit from the lighting.  This might be preferred when dealing with the mortar between bricks in a brick wall texture.

 

Two things I still have to figure out are what that preferred grayscale range is for alpha and the differences between a backing plane/3D shell and a simple environment map alpha, either plain or one with a flare spot to simulate a highlight.  Obviously an envmap would be much easier.  Off to putter with those today and tomorrow.

 
@MerricksDad - Glad you're getting some use out of it!  First off, there isn't any TXI information used in the demo module.  I compiled the models only to cut down on the loading times.  The problems you had with the torus knot displaying appear to be an animesh issue, I'm thinking.  I will say on my AMD video card, turning off the env mapping on creatures blew the lighting away for me as well.  I haven't seen that before.  That doesn't bug me too much, I assume everyone runs with env mapping on creatures turned on.  But it's interesting.

 

Because envmaps are heavily affected by smoothing groups and the angle of the face normal, maybe you would get more use out of a cubemap?  The default one, ttr01__env is basically the worst cubemap ever, ever, but it's not a bad place to get ideas from.

               
               

               
            

[Legacy_Tarot Redhand]

               

In case you are interested here is my experience with the demo. First off my video card is a mid range one - an nvidia geforce gtx 750ti. The 2 planes work just fine. The snaky/animated Celtic knot thingy works when I am positioned correctly although there is a wierd rippling effect in places. The teapot... Ah the teapot... Interesting. The main body and lid of the teapot works fine. The spout only displays the bump mapping at its base where it meets the body of the teapot. For me there is no bump mapping on the handle of the teapot that I can see.

 

TR

               
               

               
            

[Legacy_OldTimeRadio]

               

Thanks for the feedback!  That basically sounds like what I see.  The weird rippling effect on the torus knot is just the texture moving over the segments.  It even looks like that in 3DS Max.  The main thing is the planes and body of the teapot should look basically like they are in the video.  What happens if you aren't positioned correctly in regards to the torus knot?  Just to be clear, this isn't bump mapping just an attempt at visual trickery.

               
               

               
            

[Legacy_Tarot Redhand]

               

In that case it looks similar to the teapot handle. I haven't played around with it at all but I suspect that if there was brighter lighting on that torus I might not have to be quite so close to it in order to perceive the effect.

 

TR

               
               

               
            

[Legacy_MerricksDad]

               

I think what you have come up with is less a bump map and more what Torchlight 2 calls a specular map. I had been trying to figure out how to best use that when I did my Drow. I also played with it on the original low-poly Malkizid. I thought it might make his white ivory skin skiny, but not too shiny. Never did get it right. The new work I am doing on the Drow kit can make use of your techniques shown in the video quite a bit because it is ok with me that it only lights up areas the camera is looking at, or slightly offset from.

 

I also tried the plane texture as a flat ground placeable. I cannot get the OC camera angles to force a total inversion on the specular map, so that doesn't do me any good as is. However, knowing now how the specular map works, I just have to change the position of the shiny spot on the map image and I should be able to get black to white inversion as I pass by or rotate. That might make it more useful to others for textures on landscape.

               
               

               
            

[Legacy_OldTimeRadio]

               

The alpha in a texture is basically the specular map when it's not used for transparency.  I mean, it technically fits the definition of a specular map, anyway.  BTW, I don' t know how much this will help, but this envmap might be useful starting point if you're trying to get that subsurface scattering of light that makes skin look like skin.  It's a material for Scuptris created by MaCrea.  These types of maps were used for the effect in this demo.

  

I also tried the plane texture as a flat ground placeable. I cannot get the OC camera angles to force a total inversion on the specular map, so that doesn't do me any good as is.

 

Were you getting the thing where it looks like certain parts are raised when you look at it one way, then depressed when you look at it the other way?  If so, there is a possibility that figuring in an ambient occlusion map into the specular channel (instead of the Red channel from a normal map) might make very flat, carpet-y things look more "normal".  BTW, for creation of all my different map types right now I'm just using InsaneBump for Windows.  It's free, you can download and play with that here.

               
               

               
            

[Legacy_MerricksDad]

               

 When I invert your stone base texture, then apply the map to it, when viewed top down, the best I can get is shiny on one side, but never inverted to dark on the same side. If I instead do only those things I listed above on your left spinning plane, I can get only the stone edges to invert from white to black, which makes it look EXACTLY the way you think normal mapping should work, except that it only functions from the angle of the camera, not the angle of the light source.

 

Let me repack what I changed, and send it back to you.


https://www.dropbox....emo_ret.7z?dl=0

               
               

               
            

[Legacy_OldTimeRadio]

               

Thank you very much for including the sample!  Okay, bear with me, what it looks like you're saying is that otr_brown.tga (which is a grayscale sphere-looking environemnt map) is playing off the surface of plc_a04.mdl in such a way that it's only illuminating one corner of the texture.  Is that correct?  If that's not what this is about, can you quickly take a screenshot and have an arrow pointing to what you are talking about?

 

I mean, as an envmap, it doesn't take light into account as far as angles go.

               
               

               
            

[Legacy_MerricksDad]

               

 

When I pause it so I can properly examine the camera angle aspects, this is what I see. When I view it mostly face on, adjusted for the offset in the envmap image, the rock highlights and shadows are in one orientation. The second image shows about 90 rotation around the envmap sphere, where 50% gray is more likely to occur, making highlight and shadow blend to gray. The third is about 180 on the envmap sphere, switching the highlight and shadow. I'm just saying this is what we'd expect from a good bump map, if only we could get it to do this via light source vectors rather than camera vectors. It ranks right up there in irritation value with emitting chunks and ALL the chunks having to face the exact same direction = area Y axis.

 

If you find some more layers we can poke with, I'll be very happy to poke around with those. So far I'm not seeing anything special on my end with non-gray-scale env maps.

 

I did play a bit with env maps combined with model opacity changes. When you combine those, you get a little bit of opacity, and a little bit of extra shine. Something in the engine hardcodes at least a percent of alpha value to envmap request if you have a defined envmap for the object. I noticed this when playing with my gem-based weapons, and holdable gems and orbs. I'd really like it if I could completely confine the two processes, and yet allow them both in a model. An alternative is to create two models, place them in the same x/y/z position, and have one display a true texture without shine, but with some good alpha value, and then have another overlay it and place the shine. I know you can make use of this differently on different types of model. For instance, the discovery of the bump replacement image you pointed out worked wonders on character models, especially when you could define replacement textures and envmapping right in the txi and have it work properly.


I was hoping to apply two env maps to the same object, using multiple meshes, or multiple objects. The only way I see of being able to do that is to emit copies of the placeable with different envmaps set to each VFX. I'm hoping that by applying two env maps to the object, I can use that cyan to magenta normal map image and get env mapping in two directions, or on at least two axes.

 

I was really hoping to have envmapping take light into account, because at first glance, that is what it looks like is happening in the game. But when you really look at it, you definitely find that the camera is the fake light source, and I'm not overly happy with that.

               
               

               
            

[Legacy_OldTimeRadio]

               

Drop this replacement otr_brown.tga into your hak and look at that flat plane again from different angles.

 

For those playing along at home, here's a video of what this new envmap looks like on a plane.

               
               

               
            

[Legacy_OldTimeRadio]

               

When I pause it so I can properly examine the camera angle aspects, this is what I see. When I view it mostly face on, adjusted for the offset in the envmap image, the rock highlights and shadows are in one orientation. The second image shows about 90 rotation around the envmap sphere, where 50% gray is more likely to occur, making highlight and shadow blend to gray. The third is about 180 on the envmap sphere, switching the highlight and shadow. I'm just saying this is what we'd expect from a good bump map, if only we could get it to do this via light source vectors rather than camera vectors.

Oh, I hear ya. This is why the isdiffusebumpmap TXI stuff still gives me the occasional facial tic.

 

I was hoping to apply two env maps to the same object, using multiple meshes, or multiple objects. The only way I see of being able to do that is to emit copies of the placeable with different envmaps set to each VFX. I'm hoping that by applying two env maps to the object, I can use that cyan to magenta normal map image and get env mapping in two directions, or on at least two axes.

Smart thinking! It's too bad some basic ASCII commands (tverts1-3 & texindices1-3, for instance) are still as mysterious as some TXI commands.  If we knew more about those, maybe things like you suggest would be easier. 

               
               

               
            

[Legacy_MerricksDad]

               

I played around with isbumpmap and bumpmaptexture and they do work to an extent. I just can't figure out exactly what file format to use.

 

When I specify isbumpmap alone, it crashes the toolset and the engine.

 

If I use isbumpmap and supply a bumpmaptexture or bumpyshinytexture (they seem to point the engine to the same thing) I can get an image to load, but it is mangled. I know the image is trying to load because if I save the image in a different format, the image changes. Both efforts crash the engine but not the toolset.

 

If I save the image as 24 bit with alpha layer in compressed format, I can see it reading the data.

 

 

If I instead save it not compressed but still in 24 bit with alpha channel, you get this instead

 

 

If I save the image in 8 bit I get the same as the second picture compressed or not, which makes no sense at all. It should be different. The same is true with 16 bit versions.

 

Switching to no alpha channel, I can save the image as 24 bit uncompressed and get it to load another image.

 

 

But saving it 24 compressed crashes the toolset instantly. Trying 8 bit uncompressed gives this:

 

 

And 8 bit compressed gives the previous again.

 

I think the bumpmap loader is expecting something other than a TGA file. I may try some other formats to see what it wants. If I try RAW, maybe I can figure out exactly what it is doing to the data, and that might help me find out what format header it expects.