View Full Version : pixel for pixel rendering

05 May 2006, 03:14 AM
Hey all, I need to render an object and its texture pixel for pixel, no filtering, no aliasing, no motion blur, no nothing. Each UV point and its corrisponding pixel on the texture have to be exact. Unfortunately I have not been able to figure out how to do this in xsi or maya.

the goal is to render an object with a texture I made of Red/Green and Black Values, where every pixel is a different R/G value from 255-0. then each uved pixel will have a different colour value eg (u=12,v=2048 == R=021.62, G=255)

Thanks for anyhelp.


05 May 2006, 04:46 AM
what you're asking is pretty much impossible in most conditions.
in first place a pixel on the texture will almost never correspond to a texel looked up for the final raster product, as UVs, camera etc. all contribute to make the screen space different from the UVspace.

the only way to not get any blending is using AA at 0/0 without any filtering and turning off mipmapping, that means that every pixel only gets one sampling operation and the return will be the raw looked up texel; this still doesn't guarantee that all the pixels of your texture will be looked up.

it would be easier to know what you're trying to achieve, because it sounds like you're aiming for a precise result, but you're failing to understand what would be the best process to get you there.

05 May 2006, 08:25 AM
Thanks for your input Jaco, here is the end goal.

Once the Object is rendered with the R/G map, all the pixels of the textured object should each have a unique color value. then take this render into a compositing package where you assign Green values to the U and Red Values to the V (using whatever node your package needs to do this). now you can assign an actual texture(not the R/G texture) to that UV node where it applies it to your render via the R/G values converting them into UV points of the texture.

The Benifit, Render a rotation of your character textured with the R/G texture(Constant shaded) and apply your texture in your comp program. now you can see texture changes directly on your rendered image and do a complete rotation without having to re-render the 3d scn.

some would say, well it would just be simpler to forget it and render the texture in xsi. But I have a few tasks where this technique would be really handy, not like the example above.

Hope that helps. :)


05 May 2006, 09:01 AM
you should have said it right away that was a UV RGB pass for comp man :)

you can look up the UVs and use that vector as a colour.
node>texture space generator>projection

that returns UVs as a vector, you can pipe it straight into the material's surface (a vector2color node will get in the way) and you'll have your RG = UV pass right away

all the pixels will then have a unique value (provided you don't have UV overlaps and AA doesn't screw with you), as the UV sampling will be per pixel by UV space.
antialiasing and jittering might scramble things around a bit, especially if you have the object overlapping itself at several depths, so that's your main enemy.

once you have that you can use a node in shake that reads that on-screen, the UVs from a file of sorts, and it can map things by a simple lookup wherever you want.

if you can make some basic assumptions you can also map it with a couple pixel parsing nodes right away and skip doing any custom dev:
parse (inside the alpha) the UV render to find a non black colour and look up for each pixel its R and G values.
when you have that value, look up your texture image at that point, and dump the colour you read into the original pixel position.

so if you get something like 0.001R 0.001G you can lookup the bottomleft corner of your image and get that value in the original pixel's raster coordinates, if you read 0.5R 0.5G, pick the colour of the centermost pixel of your texture and use that... and so on and on.

use a self-antialiasing node if you want to AA the pass (which you might want to do) but don't AA the edges, and even that might screw you on Z overlaps.
infact, ideally, you could want to oversample yourself by rendering with 0/0 AA at twice the res for the UVs pass, so that you can discretize that oversampled render, and look up 4 pixels for each normal res pixels, find the corresponding colour for each, and average those, this will be the equivalent of a very primitive, but effective, 1/1 box 1-1 AA pass.

05 May 2006, 01:34 AM
rad, thanks Raf. so much better than using an R/G image texture that is super hi res.

I will let you knwo if I encounter any problems

Thanks again


CGTalk Moderation
05 May 2006, 01:34 AM
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.