Light.. back the Normal

Helper

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

On 26/06/2006 at 23:35, xxxxxxxx wrote:

Renato, I think he means that you might want to flip the normal of the polygon and use that 'backfacing normal' instead of the proper normal. The easiest way to flip a normal is to negate the vector:

Vector normal = A % B; // or however you obtained the polygons normal
Vector invNormal = -normal;

This is the normal of the same polygon but having reverse winding order.

Helper

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

On 27/06/2006 at 05:26, xxxxxxxx wrote:

Hi Robert,

ok, but when i'm looping trought the ligts, lv is == zero when for the polygons are back to the light.
what i did is to calculate by hand the rest but the basevolumedata value are not filled correcly by the c4d core.

Let me investigate

Cheers
Renato T.

Helper

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

On 27/06/2006 at 07:06, xxxxxxxx wrote:

Could you provide a class derivation to lv? Is this the one from BaseVolumeData::RayLight?

Also, I see a 'back_orign' which is the 'backprojected normal' (which may be the reversed polygon normal?).

I must admit that the entire enterprise looks extremely complicated (more class members and methods than I care to look over on a regular basis).

Thanks,

Helper

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

On 27/06/2006 at 08:33, xxxxxxxx wrote:

Hello Robert,

i'm inside the loop of the lights.

lv is derived from RayLightComponen::lv and when the light is back to the normal, lv=Vector(0.0);

Now i'm calculating backlight when i detect lv==0.0 and make myself the vector from light and back_p. It work.. but it's the correct way?
Another things is: how i can calculate the shadowmap from the backlight?

Thanks Robert
Renato T.

Helper

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

On 27/06/2006 at 20:58, xxxxxxxx wrote:

I forgot to tell you that the RayLightComponent->col is also 0.0 some time this will cause a orizontal black band (not ever).

Cheers
Renato T.

Helper

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

On 29/06/2006 at 05:11, xxxxxxxx wrote:

Any help to how make RayLightComponent::lv and RayLightComponent::col valids for light back to the normal?

Thanks
Renato T.

Helper

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

On 03/07/2006 at 07:40, xxxxxxxx wrote:

No idea, but... the manual says RayLightComponent::col is the color of the lightsource. So, how about using raylight->light->color ?
If calculating the lightvector works for you, i guess it's okay..

Helper

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

On 03/07/2006 at 10:31, xxxxxxxx wrote:

I'm very sorry for the delay. I will look into this issue immediately!

Helper

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

On 03/07/2006 at 10:41, xxxxxxxx wrote:

With 9.5+ there is a new field IlluminanceSurfacePointData::cosine_cutoff that seems to control this behaviour. With 9.1 I assume this means that cosine_cutoff == TRUE always. So your solution seems to be correct in 9.1, though it might be worth to see if the cosine_cutoff code is faster on 9.5+.

Helper

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

On 03/07/2006 at 11:16, xxxxxxxx wrote:

Thanks Mikael,

This mean that with the 9.1 sdk i must calculate the light vector and the light color myself?
Sometime with manual calculation of these vector i get zero for color...
Anyway seem that with the 9.5 this issue can resolved

Thanks for your answer
Thanks Michael too.

Cheers
Renato T.

Helper

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

On 08/07/2006 at 04:24, xxxxxxxx wrote:

Yes, I just got a reply from the developers that the only way in 9.1- is to flip the ray offset and vector (along with cosc) if it's on the wrong side.

Helper

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

On 08/07/2006 at 06:46, xxxxxxxx wrote:

Hi Mikael,

Can you tell me more? I fear that i don't understand..

Thanks
Renato

Helper

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

On 08/07/2006 at 12:45, xxxxxxxx wrote:

I just wanted to clarify that the current (slow) way that you have already been using is the only way in 9.1-.

Helper

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

On 08/07/2006 at 16:18, xxxxxxxx wrote:

Thanks for info... but seem not much slow today

Helper

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

On 17/08/2006 at 21:00, xxxxxxxx wrote:

"is to flip the ray offset and vector (along with cosc) if it's on the wrong side."

Where i can flip the Ray or the surface normal?
I have lc->col = 0 when the light is back..
The raylight->light->color is the color of the light.
The lc-col take in consideration the light cone.. faloff. etc.etc..
I'm sorry but, i don't know how to.

Thanks in advance
Renato T.

Helper

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

On 18/08/2006 at 08:11, xxxxxxxx wrote:

Please,

i need to fix this trouble because i can't use the 9.6 sdk and get benefit from cosine_cutoff.

Thanks
Renato T.

Helper

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

On 24/08/2006 at 13:01, xxxxxxxx wrote:

I think all it means is that if you get col==0 you need to redo the call with a flipped vector, so that the light thinks that it's on the right side of the polygon.

Helper

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

On 25/08/2006 at 06:45, xxxxxxxx wrote:

Ok, i understand.. but how i can redo the call?

I don't make any call so i don't know how i can re-make the call

Renato

Helper

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

On 07/09/2006 at 14:44, xxxxxxxx wrote:

(Removed some bump messages. Not to be seen as a criticism; by all means keep posting them if I'm slow. I'm terribly sorry for the delay.)
Ok, I see. So you're not calling the illumination function yourself but just looking in the lights returned by VolumeData::GetLight()? In that case, you're right that it wouldn't be remaking the call, of course. But what happens if you add an extra call to IlluminateSurfacePoint(), with the normal reversed, for the RayLights that are wrong in the pre-calculated GetLight() array? Wouldn't you then get the right color?

Helper

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

On 07/09/2006 at 15:17, xxxxxxxx wrote:

IlluminateSurfacePoint it's a 9.6 function. In the new sdk there is also a flag to prevent the normal.

Did you mean Illuminate on the 9.1 sdk?

Cheers
Renato