Displacement RGB ( XYZ Local )

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/11/2004 at 13:21, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   9.012 
Platform:   Windows  ; Mac  ;  Mac OSX  ; 
Language(s) :     C++  ;

---------
Please describe the evaluation process for this displacment evaluation. We are trying to duplicate it for dispalceVIEW and have fallen at the X and Y components ( Z is obviously the normal ). We are looking at the a>d poly components for the X axis but that seems to be off. When there is only movement in the red channel we are getting offsets in what we assume is X & Y. Odd. Info appreciated.

darf

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/11/2004 at 01:29, xxxxxxxx wrote:

Hey darf

When i worked with the displacement in r9 demo, i had the feeling, they derived those other two components of the coordinate system they use for displacement from the direction of u and v. That's why the result was dependent of the projection. That's my guess.

chris

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/11/2004 at 05:00, xxxxxxxx wrote:

Hi,

the manual says
Red = X, Green = Y, Blue = Z

but honestly. I just tried putting a color shader into the displacement channel and the RGB local results are more than unsatisfying. I tried it on a cube and only on the top face. The face did not once just move upward but, no matter which color I used, the face always rotated in some way.

So it either does not use the normal or it is simply buggy. One thing is clear. It´s unusable in this state.

Good luck anyway.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/11/2004 at 00:17, xxxxxxxx wrote:

According to the developers, R is X is ddu, G is Y is ddv and B is Z is the phong normal.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/11/2004 at 13:07, xxxxxxxx wrote:

Erhmm...

OK, this may be correct in some instances. Seems that poly.b vertice in a triangle isn't moved in X ( possibly Y ) at all? Huh, strange. Would appreciate the algorithm so it could be implemented properly since it seems a bit esoteric.

Best Regards,
darf

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/11/2004 at 04:17, xxxxxxxx wrote:

Howdy again,

This is important. Can we expect that the pseudo algorithm will get posted?

Best Regards,
David Farmer

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/11/2004 at 14:20, xxxxxxxx wrote:

Any chance you could send a scene showing such triangles? They didn't show up in my test file. To me it seems that the contribution from neightbouring polygons is simply added somehow; thus if two polygons conflict the result might be 0 in one coordinate. Anyway, I've asked for a more detailed description of the algorithm.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/11/2004 at 10:02, xxxxxxxx wrote:

Just create a polygon primitive. make it a triangle. Apply texture with displacement. I would guess the direction is being evaluated from a to c, b to d, etc. If there is no fourth component to the poly it is zero displacment. All speculation of course. How are we doing on this? Render mode is slow and I would like to wrap this up before J3 ships.

Regards,
darf

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 08/12/2004 at 01:31, xxxxxxxx wrote:

I believe the DU/DV directions are the same as ddu/ddv in BaseVolumeData. Do you have access to those? In that case the pseudo algorithm would simply be:

    
    
    p = p + z*n + x*ddu + y*ddv

Then it looks like the contribution from different polygons is either averaged together or added (just a constant factor difference that should be easy to detect).