Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush Python API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Recent
    • Tags
    • Users
    • Login

    Tracegeometry revisited

    Scheduled Pinned Locked Moved SDK Help
    1 Posts 0 Posters 134 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H Offline
      Helper
      last edited by

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

      On 03/08/2008 at 08:16, xxxxxxxx wrote:

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

      ---------
      Hi,

      I took a look at my tracegeometry-problam again (discussed here before), and I still can't get my head around it. I'm opening a new thread because the old one is a little cluttered, and I'd like to try and get a better formulation of the problem.

      So issue still is:

      I am writing a channelshader. It uses a call of tracegeometry() to determine the depth of the shaded object in the direction of the viewing ray and calculates a color value from that - the thinner the depth, the brighter the color. That works fine so far, gives a xray-like effect.

      But as soon as I use this shader in the transparency channel (the intention is to get some absorbtion effect, were a higher depth of the material would give a darker color in my shader, so it is less transparent), any point that is shadowed by my material will not recieve a shadow from objects between my object and the light source. This is also somewhat dependent from the viewing angle (one light with hard shadows, the sphere has my shader in the transparency channel) :

      This sharp edge is always perfectly horizontal.

      So, I guess I'm doing something wrong here - probably killing something in the volumedata/shaderdata, as this artifacts occur along all render threads. If i render it with 4 threads, all renderlines ignore the shadow or apply it at the same time while rendering - so this is some kind of sideeffect, overwriting something, i guess. Also, even if I don't actually use the result of tracegeometry and just return, say, 50% grey as result from the shader,this artifacts still occur.

      So - calling tracegeometry in the shader during shadow calculation leads to this problems. Leave it out, everything works. Is there anything I need to take into consideration with tracegeometry? I didn't find any restrictions with it in the documentation, but this call seems to break something in the renderer.

      The call is in

      Vector DepthClass::Output(PluginShader *sh, ChannelData *sd) :

      > `

        
      \>  (...testing if i have volumedata available at all...)  
      \>    
      \>  Ray* testray = gNew Ray(*sd->vd->ray);  
      \>              
      \>  testray->p.x = sd->vd->p.x; //set ray origin to surface, leave direction  
      \>  testray->p.y = sd->vd->p.y;  
      \>  testray->p.z = sd->vd->p.z;  
      \>    
      \>  bool testb = sd->vd->TraceGeometry(testray, 10000, 0, si);  
      \>    
      \>  (...calculate value from the distance of si->p to the surface point and delete the allocated objects...)  
      \>  
      

      `

      This is enough to create this artifacts. Matthias mentioned to check for shadow manually, but I don't think this is it - even if i return a constant this error occurs. As soon as I remove tracegeometry, its fine, shadow and all. Tracegeometry aparently modifies something in the shader/volumedata that is used for shadow calculation (as it works fine in luminance/color/...), but I can't find anything about that in the documentation - and there are too many variables to find out whats wrong by hand.

      Maybe it just can't be used in the transparency channel (would be dissapointing, though.)? The behaviour is the same in the R10.5 Demo, so I don't think its a bug, either.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post