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 = Zbut 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*ddvThen 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).