PDA

View Full Version : Accessing map values by UV coordinates?


martinB
04-21-2008, 11:05 PM
I need some help for accessing the color values generated by a map.

Instead of directly reading the pixels of a bitmap, I need to access the values computed by a map that uses the bitmap as base. I have UV coordinates and want the values at that position from the map.

So I am looking for something like getPixels(), but only for a map, not for a bitmap.

Unfortunately, I cannot use renderMap() to compute a bitmap from the map (and then use getPixels), since my source bitmap is larger than 10k * 10k and renderMap() will not render a map at that size (I get a system exception). And since I need subpixel accuracy, rendering the map would produce very large amounts of data anay, if I would have to render it to even higher resolution...

Therefore, I need to find a way to query the map for it's value, given a specific point in UV coordinates.

Any thoughts much appreciated!
Thanks!
-- MartinB

ZeBoxx2
04-22-2008, 02:22 AM
Just musing here, as there isn't any way in MaxScript to evaluate a map (ah, how I wish.)...

If your map is, at its basis, still a bitmapTexture, you could use the Crop/Place options to only get the small section you're interested in and then renderMap to the lower resolution.

If that's not an option (especially if there's 2D procedural maps involved, which you can't set Crop/Place options on), you'll probably end up having to play with some manner of rendering after all.. either leveraging RTT (ick), or a standard render() call. If you create a small tri or quad with each TVert the same U,V values and render that - that should render fairly quickly. Then you can still getPixel from the rendered result.

This will obviously be slower than how a renderer evaluates a map in the first place, and won't help you if you need a proper evaluation of a 3D map in U,V,W space either. So if you have plugin writing skills, perhaps try your hand at a renderer (not sure if the evaluation calls are valid outside of a renderer - the SDK jumps all over the place) :)

martinB
04-22-2008, 07:43 AM
If your map is, at its basis, still a bitmapTexture, you could use the Crop/Place options to only get the small section you're interested in and then renderMap to the lower resolution.

Nice thinking. Unfortunately, the map I am looking at does not have crop control.

If you create a small tri or quad with each TVert the same U,V values and render that - that should render fairly quickly. Then you can still getPixel from the rendered result.

That's not such a bad idea, thank you. A bit cumbersome to set up the triangle, the camera, the render call, the flat lighting, just to get a single pixel, but at least it is doable.

I'll give that a try unless someone else has a better idea?

Thanks!
-- MartinB

ZeBoxx2
04-22-2008, 09:43 AM
Well, the flat lighting is easy enough - make the material (presuming a Standard material) self-illuminated, disable the highlight, make sure the map is in the diffuse map slot and off you go.

If you need multiple UV locations you can create multiple tris/quads and render them all out in 1 go to skip on some of the render call overhead.

Still a bit klunky, but there you go. 3D Procedurals, if this is supposed to match some model, will be more difficult - that's where you'd really just have to RTT the actual model.

martinB
04-22-2008, 10:38 AM
Well, the flat lighting is easy enough - make the material (presuming a Standard material) self-illuminated, disable the highlight, make sure the map is in the diffuse map slot and off you go.

... unless there are other lights in the scene that add to the self-illumination. Basically what I would need is the equivalent of the "flat" viewport shading.

Other feature that might get in the way with this method are exposure control, funky render settings (e.g. maps off), render filter settings...

If you need multiple UV locations you can create multiple tris/quads and render them all out in 1 go to skip on some of the render call overhead.

Yep, good point. Loading a 20k texture for each render call would be quite slow otherwise.

-- MartinB

ZeBoxx2
04-22-2008, 02:36 PM
... unless there are other lights in the scene that add to the self-illumination.
A self-illuminated surface doesn't care about other illumination, actually; at least in Scanline, Brazil r/s, Mental Ray - not sure how other renderers might handle that :)

Other feature that might get in the way with this method are exposure control, funky render settings (e.g. maps off), render filter settings...
Yep, that's definitely true.

CGTalk Moderation
04-22-2008, 02:36 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.