87 réponses à ce sujet

[CaveGnome]

This is a very convincing effect. If used on tile floors or walls, I see huge potential... Hey, one of my secret wishes is a lunar/asteroid tileset (na, nothing to do with a certain famous space rock named B.... ;-)

[OldTimeRadio]

I am starting to understand a leetle bit more and I thought I would show off some comparison shots of a teapot model with a green light (from placeables.2da) next to it.  Before I go on, I just wanted to underscore that the process that I wrote about creates a texture which is transparent to some degree.  So some of the things below either involve coloring the transparent texture with an envmap or having something "under" it with a texture.

 

 First, the "control" picture with the regular rock texture applied to a teapot.  This is the picture I derived the normal map from, with no modifications or anything:

 

Here is that method I posted about in the previous two messages, except instead of using a sort of a square sphere map that I linked to, this is just a solid brown 64x64 envmap:

Notice how the green light "paints" the surface?  I'll get to that a little bit later in the post.  

 

But what if you didn't want a single-color surface and wanted bits of the original texture to show through?  Well, just duplicate the model and texture it with your original texture or, as here, basically mimic the color of an envmap on a full-sized texture but with portions of the original bitmap "showing through".  No need to change the scale of the models, as long as the model with the transparent texture is the child (hierarchy-wise) of the diffuse-textured one, it'll draw after the diffuse and the effect will composite correctly.  This is what that looks like:

 

Anyway, those are some screenshots of different techniques and what they look like.  They are by no means all the different ways you can tweak this situation, just the ones I thought of and had time to do this evening.

 

On to more general things: So what tricks are responsible for these looking like they have more depth?  Part of it is definitely how the textures are put together.  By copying the Red into Alpha and Green into the other channels, you basically wind up with an 8-bit image...with an alpha layer.   How the alpha and the grayscale in the texture interact is definitely a part of it.  But the following phenomena also seems to be partly at play:

 

 

The way light "paints" a transparent model.  Or, I should say, at least the models I've set myself up with.  I have to determine if there's something special I'm doing, model-wise.  Anyway, that's me standing in the center of a big sphere model with a transparent texture (using the technique I outlined above) with a placeables.2da light above it and in an Interior, Torch-Lit only environment.  Notice how where the light hits it, it becomes opaque?  If I were to pull out my torch model and walk outside the sphere, that whole side would go from being transparent to opaque- and be the color of whatever light my torch was putting off.  Like I've said, I've seen this before and not paid too much attention to it but there might be something Interesting™ going on.  I'm not so sure there is.  I'm pretty sure there isn't.  But there might be.  If there was, it would be something where a light calculation was treating that surface as though they were surface normals.  I really don't think that's the case.  Howwwwwever...see the buttons above and the radial pleats they have?  In this video you can see the pleats apparently appear and disappear when I move my camera around.  Only the first 25-30 seconds are worth watching. 

 

I'm not sure what's up with that.

[Jedijax]

I have no idea what the hell you're talking about most of the time, but you're a genius. I never thought NWN was capable of those.

Close

[MerricksDad]

Is this still something which can only be done with shiny water enabled, or otherwise on a video card which supports effects like shiny water?

[OldTimeRadio]

@Jedijax - Ha- thank you!  Don't jinx me!     
 
@MerricksDad - This should all just be achievable with regular lighting.  Bet let's put that to the test!  
 

 
Download the demo module...
 

 
I'd love feedback if it works but especially if it doesn't!
 
NOTE: The plane on the left may appear a little more lit.  I think that's just because there's another light near the teapot whose rays are also hitting it.

[MerricksDad]

On mine, the snake looking tube is transparent with darker spots sliding along it. It doesn't shine for me at all. The other parts are about the same, but I can see some variation in how the lighting works. The teapot is more brown on mine, and the right plane is more well lit than yours, making it look less shiny overall. When I walk past any of them with a torch, I don't get as much play as in your video. Some of this could be my display settings on the monitor. I can't explain yet the lack of texture on the snake tube.

 

Edit: I don't see the globe-shaped env map in the hack, that is probably the only difference.

[Fester Pot]

Does this mean authors of tilesets will be able to update their textures and offer a new form of visual enjoyment for those of us in the community?

The latest picture example. How about the grass to make it look like grass, vs. looking like a carpet using the information you've found.

Or building textures that look smooth (ala plain texture example) but upgraded by the tileset authors to make it look like rock (ala two models example).

Is that what the direction of this new information you've provided will move CC makers toward?

FP!

[Zwerkules]

Anyway, that's me standing in the center of a big sphere model with a transparent texture (using the technique I outlined above) with a placeables.2da light above it and in an Interior, Torch-Lit only environment.  Notice how where the light hits it, it becomes opaque?  If I were to pull out my torch model and walk outside the sphere, that whole side would go from being transparent to opaque- and be the color of whatever light my torch was putting off.  Like I've said, I've seen this before and not paid too much attention to it but there might be something Interesting™ going on.  I'm not so sure there is.  I'm pretty sure there isn't.  But there might be.

 

Is there a txi with 'blending additive' involved somewhere?

[OldTimeRadio]

@MerricksDad - Thank you for downloading it and finding that error, MD!  I'd inadvertently left that file out.  It's in the updated pack at the download link above.  You can see the effect of that most easily by pausing the game and moving your camera around: It should cause highlights to play over the surface of the torus knot when paused.  I's not sure about the other differences though I would chalk those up to a difference in monitor calibration settings.  I know you're busy but if you can send me a screenshot (oldtimeradionwn at google's mail service dot com) of what you're seeing using the default lighting settings in the demo I can compare that to a screenshot from the same-ish view on my end.  If they're generally the same, it's a difference in displays.  AFAIK, though, the OpenGL coloring, NWN's lighting, should be basically the same across systems.
 

Does this mean authors of tilesets will be able to update their textures and offer a new form of visual enjoyment for those of us in the community?

Sure...if they want!  But for that to happen I have a ton of footwork to do and, even if I achieve what I consider a wild success, there's still no guarantee that anyone will do anything with it.  There are a lot of factors which figure into how widely adopted something new is, and which exist regardless of quality or utility.  I don't worry so much about that, but it's part of the reality of the situation. 
 
I still have a lot of ground to cover, though.  Just a few:
* Which default Ambient and Diffuse look better on the model.  All 1's vs all .588 or whatever vs Diffuse .8 & Ambient .2 vs something yet unknown
* Whether other settings, such as those applied by the TriMesh modifier (and regardless of their settings) might negatively impact or help with the effect
* How well those things blend in with regular NWN tiles/placeables.  These look good in regular daylight so that's bolstering.
* How to reproduce this effect with other textures or, put another way, what textures are a good candidate for this process?
* Appropriate range of grayscale (this is huge) which have to be used to make the effect work best.
* Is this effect disrupted by objects with different shapes/smoothing groups?  (Thankfully, looks pretty persistent)
 
And so on and so on.
 

The latest picture example. How about the grass to make it look like grass, vs. looking like a carpet using the information you've found.

Since I still have quite a bit to figure out, I'm just going to stick with bumpy stuff. I've tried a few things like cobblestones and while I can sort of conceptualize how to make them look better, doing it is a bit beyond my skills at the moment. So just bumpy stuff for now.
 

Or building textures that look smooth (ala plain texture example) but upgraded by the tileset authors to make it look like rock (ala two models example).

Is that what the direction of this new information you've provided will move CC makers toward?

If I can exploit this to some measurably nicer and reproducable effect, absolutely.  But even I am not convinced this is some kind of panacea.  A demo module full of side-by-side comparisons once I've answered the bullet-pointed questions/issue above is really the only way to know how much utility it'll have.

[OldTimeRadio]

Is there a txi with 'blending additive' involved somewhere?

Nope, it should be just that missing texture that MD mentioned.  I stayed away blending additive in this current demo.  It could be very nice in the future but my experiments with it indicated I really needed to get a handle on the grayscale range in my alpha and my envmap first.  Beyond my skills at the moment.  The plane on the right is one transparent plane with an envmap like the one on the taurus knot on the demo and one backing plane.  The one on the left is just a basic textured plane.

 

Crap, misread your message.  Yes, there is a good chance I was using blending additive in there.  That would absolutely make sense.  I try so many different things so quickly that I often lose track of what settings I'm using until something stands out.

[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.

[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.

 

[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.

[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.

[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

[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.

[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

[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.

[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.

[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

[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.

[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.

[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.

[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. 

[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.