I don't suppose anyone knows how to generate bump vectors for simplex noise...?

Thomas -- oh heck, you're a real shader coder?? Cool.

So uh... I don't suppose you have any good advice on generating bump vectors from multiple samples (forum discussion thread), do you? After getting the regular single-sample simplex bump vector generation to work, I realized I also need the more flexible (but slower) multi-sampling bump generation, but have no idea how to calculate good epsilon offsets that aren't going to break at very small or very large scales.
 
Heheheh - well, not as "real" as you may hope ;-)

I got the impression that you are way beyond me when it comes to actual coding - I'm pretty much still a C guy with only little C++ knowledge. I can hardly follow you guys here when you are talking the wonders of C++ 11 :)

But I managed to compile the Specular Node example with VC++ Express 2012 today as 64 Bit dll, so I'm rather happy.

As far as your question goes:
In Mental Ray, this value is often user setable, since sometimes it's beneficial to be able to select the value depending on what kind of texture you use or what look you want.
Otherwise I think you could take some portion of the "spotsize" (if that concept exists in LW?). Since this gives you a value related to the currently sampled spot.

I read your thread about this and wondered if the internal result from the simplex noise couldn't be used directly for speeds sake.
You want to use the LW "Functions", right?
Couldn't you "bend" those normals with the function curve (sorry, don't know yet how those things work in LW, I just started today to look into this)?
What the functions should do (I guess) is that instead of a linear interpolation between the two maxima - perpendicular to the surface and "laying flat" on the surface - the curve is used.
So if you assume that the extremes stay unchanged and only the values in between are changed (like a photoshop curve with fixed black and white point) you could use a dot product to find a zero to 1 value between the surface normal and your bump vector from the noise. That value would be the input into the function curve. The result of the function curve (not sure how you get that delivered?) would then tell you how much you have to bend the vector up or down, keeping it's (surface local) x and z direction as is.

Hm - does that make any sense? I need to re-learn about those concepts in LW first to know the right syntax ;-)
And I'm not sure if I understood the problem right.

Cheers,

Tom
 
Thomas Helzle said:
Heheheh - well, not as "real" as you may hope ;-)

I got the impression that you are way beyond me when it comes to actual coding - I'm pretty much still a C guy with only little C++ knowledge. I can hardly follow you guys here when you are talking the wonders of C++ 11 :)
Click to expand...

Oooh! You're in for a fun time, once Microsoft gets their C++11 compiler up to spec. I used to be a dyed-in-the-wool C coder, but after I wound up implementing a full object system in C99 I realized it would just be cleaner and easier to use C++. C++11 is like a whole new world and I can't recommend it enough. :)

A good example would be the NodeBase.h template object in my node plugin source code. It saves me having to repeat a bunch of boilerplate in getting the callbacks set up, while still giving me the ability to override the behavior of any particular callback on a node-by-node basis.


In Mental Ray, this value is often user setable, since sometimes it's beneficial to be able to select the value depending on what kind of texture you use or what look you want.
Otherwise I think you could take some portion of the "spotsize" (if that concept exists in LW?). Since this gives you a value related to the currently sampled spot.
Click to expand...

Ah, but that could potentially miss small-scale detail that's smaller than the spot size, right? Wouldn't that result in bump artifacts?

Right now I'm trying to find a good small value that will handle the widest range of scene scale before hitting precision limits. (For instance, if I use a really tiny number like 0.0000001, or 1/1000 of a millimeter and then model a planet at full scale using bump maps, there's a good chance that the offset value will truncate to 0.0 and the bumps would simply not appear.) I'm very curious as to what the Lightwave noise nodes use -- is it a constant or do they dynamically generate the offset somehow. No idea.


I read your thread about this and wondered if the internal result from the simplex noise couldn't be used directly for speeds sake.
Click to expand...

Yep, got that. I've renamed the output to "Fast Bump", and the others will be "Bump from Alpha" (uses alpha channel directly -- my noise node allows for incoming foreground and background alpha input), and "Bump from Noise" which will be just like "Fast Bump" only done via multi-sampling instead of using the directly-generated simplex bump gradient -- allowing me to apply Function and Contrast.


You want to use the LW "Functions", right?
Couldn't you "bend" those normals with the function curve (sorry, don't know yet how those things work in LW, I just started today to look into this)?
What the functions should do (I guess) is that instead of a linear interpolation between the two maxima - perpendicular to the surface and "laying flat" on the surface - the curve is used.
Click to expand...

I couldn't figure out a way to do this that gave correct results. I tried many experiments, but if it's possible then the math is just over my head. My initial impression is that it's not possible -- Function and Contrast alter the intensity of points and it seems that the only way to appropriately alter the bump map to mirror this is to multi-sample the noise after Function and Contrast have been applied so the proper gradient can be calculated.

The bump vector doesn't actually encode a direction vector, it holds XYZ rates of change (from -1 to 1). I'm kind of embarrassed it took me so long to figure that out.
 
Last edited:
Well, the SDK example is in C, my existing code is in C, so I fear I'll stick with it for the moment ;-)


Smaller than the spot size means "invisible", no? Or giving the AA a really really hard time with sub-pixel-bump - usually not a good idea ;-)
I would think that something like half or a quarter of the spot size (is that one or three values in LW?) in each direction should do just fine. Try it out I'd say ;-)

I understand, if you have additional internal functions that also change the noise it will get pretty complicated to rebuild that as a vector offset - probably not worth it as you say.


LW seems to have it's own way of doing things compared to messiah, Mental Ray and Arnold - I'll have to see if I'll make it through - I'm easily discouraged in that regard.

Cheers,

Tom
 
I'll give the "half of spot size" a shot, although I'm not entirely sure how to handle glancing angles. LW provides a "cosine" value in the spot info I can use to determine how accurate the given spot size is, but when the size is "inaccurate", I'm not sure how I should calculate my offset. I'll try some experiments and see how they work out.

Hey, the original version of my optimizer plugins were written in C99, so if you go back to my LW Plugin page and go to the bottom of the post, the old one is still available and also includes full source. Granted, Microsoft doesn't support C99 so you won't be able to compile it directly, but it should give you a starter framework on one possible way to structure your C code for Lightwave.
 
Last edited:
Yeah, it's a bit of a learning curve. Whenever you hit something you can't figure out, ask around here. :)
 
You must log in or register to reply here.
Back
Top