particle direction driven by texture
-
Hello:)
Atm i do some r&d for getting a cartoon-look with c4d for doing a children's-book together with my girlfriend as a private project.
I found a very nice approch and technique here:
http://www.zenopelgrims.com/project-arnold-brushstroke-shader-quantize.htmlHe is using Houdini and Arnold.
So i downloaded a Demo for Arnold (c4d) to see if i can replicate this technique straight in c4d, but long story short, i cant
and i believe without coding some stuff this want be possible anyways.So i thought to rebuild his priciples with c4d and xparticles.
Lets dive into it:
What i try to achieve atm: particle rotation based on the particle color.
The particle color is given by a normal textur, this will change later.
Now it´s the easiet way to get access to the data. For my understandig the color information inside the normal texture can be seen as a vector, is that right?I am using Xpresso to get access to the color(which contains the normal data) and the x-particle roation.
By feeding the vector into a range mapper it convert to degress.
The range mapper output (degeress) is going into the particle-rotation.
There is defently something going on, and the particles are rotated individually based on there color, but somehow not right.
What i like to see is that the roation/orientation of the particles is based on the surface correcly, that means based on the normal direction.Does somebody has an i idea what went wrong here? Maybe the rangemapper settings? or is does somebody is spotting even a basic missundestandement?
If you like to have a look into the reduced testfile you are very welcome:
test-normal to roation-2.c4d
Best, Hannes
-
Hello @hannes-weikert,
Welcome to the Plugin Café and thank you for reaching out to us. I first must point out that this is a forum dedicated to the APIs of Cinema 4D and adjacent APIs as Cineware. So, both a question about Xpresso and XParticles are here formally out of scope. However, you did post already in the correct "off-topic" forum and rightfully indicate that there is some algorithmic underbelly to be explored in your problem, which is the subject of this forum. But please understand that Maxon will not provide any Xpresso or XParticles support here, meaning we will not touch such setups. When you would make use of a Python node within a Xpresso setup and have problems with that, that would be within the scope of the forum. Or in short: As long as there is no code, you will get only community support here.
With that being said, I briefly read your posting and I would point out two things:
For my understanding the color information inside the normal texture can be seen as a vector, is that right?
It depends on what XParticles does in its texture sampling, but in general that is not true. The RGB vector stored at a pixel in a normal map is not the same as the normal it is meant to represent. This is because the normal has to go from [-1, 1] on the x and y axis, and [0, -1] on the z-axis. Therefore the values must be shifted before they are the normal. The Wikipedia article on normal maps lines out some details in its Calculation section.
There is defently something going on, and the particles are rotated individually based on there color, but somehow not right.
I assume here that:
- The normal map in your image is meant to represent the normals of a sphere, i.e., they should stand out like "spikes" from the sphere.
- And you want the arrow particles to point along these normals.
- This curl-like appearance is not what you want.
It seems likely to me that you are rotating on the incorrect axis. I do not know the details of Xparticles, but it is pretty obvious from your screenshot that you only calculate one value (the rotation in the range mapper) and then set this value to either a singular axis or all axis (the Rotation port). But a normal map contains explicitly two degrees of freedom and when one constructs the frame for a normal, the third degree of freedom is usually made up with an up vector. So, in short, you are interpreting the normal map as real number, but in reality it does express a frame/transform/matrix or however you want to call it.
Cheers,
Ferdinand -
Thank you alot Ferdinand for your time, thoughs and help.
I really appreciate that:)'
I will get my head in it and try to figure it out.
