Light.. back the Normal



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

    On 25/06/2006 at 22:52, xxxxxxxx wrote:

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

    ---------
    Hi all,

    i would like to know how i can force in materialdata the result for vector lv when the light is back the normal of polygon. I see that lc->lv is equal to zero when the light is back the polygon.. i need it to calculate the backlite.

    Thanks in advance
    Renato T.



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

    On 26/06/2006 at 14:03, xxxxxxxx wrote:

    How about calling the illumination function with the reversed normal?
    regards
    /Filip



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

    On 26/06/2006 at 15:22, xxxxxxxx wrote:

    Hello Filip

    i used the back_n from volumedata.. but what do you mean about "calling the illuminaion with the reversed normal"?

    Thanks
    Renato T.



  • 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.



  • 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.



  • 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,



  • 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.



  • 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.



  • 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.



  • 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..



  • 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!



  • 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+.



  • 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.



  • 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.



  • 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



  • 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-.



  • 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 :)



  • 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.



  • 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.



  • 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.


Log in to reply