Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

no shades if sun shades activated, in Bricscad V19

I am trying to see shades in Bricscad. I activated the shades at the "Sun settings" and in the "realistic" view settings, but there is no change. No shades to be seen, not in the rendering window and not in the "realistic" representation of the 3d-model.
Please see the attached screenshot with the sun settings I chose.

I also setup the geographic location, all like instructed in the online help of bricscad.

I cannot understand why the sun, after being activated, does not appear in the "lights" list. Also, why there is no "sun" light in the possible lights that can be chosen, but only a "distant" light. It is not clear why the sun makes "separate opinion" here, and is not present in any way in the "lights list".

Could anybody help in setting the sun correctly, so that I get the 3d-model correctly illuminated and shaded?
Thank you!


  • Add a solid to 'catch' the shadows, for example a solid to represent the terrain, and invoke the _Render command.

  • I think the OP was referring to viewport rendering (visualstyles) rather than to the render command.
    Sadly, and for reasons hard to understand, sharp (traced) shadows where removed in V16 and have not been restored until now (see attached screenshot from V15, for what it looked like then).
    Probably each user coming from sketchup or a BIM-application will miss them, and the shadow maps that BricsCAD offers now can hardly be seen as a viable alternative.

    836 x 834 - 162K
    V15.jpg 161.8K
  • ^ that looks nice !

  • @Knut Hohenberg
    I just noticed there is an issue with the sun in the default V18 templates. I can't change the color (no 'dropdown'), and changing the type under 'Render Shadow Details' does not work properly. Can it be that the issue you mention is also dwg dependent?

  • @Roy Klein Gebbinck
    Yes, I think so, but I am not sure: When I create a new file right now in V19beta (from template or from scratch), the sun is stuck with RGB:180,168,132, and shadows are stuck at soft (area). The file that the screenshot was taken from exhibits the behavior you mentioned, while in other files the sun has a default of RGB:255,255,255 and works properly. However, I cannot get sharp shadows in any file, can you?
    I created a SR (SR 66314) for this in 2015, which is still unresolved.

  • edited May 2019

    I just did a quick test in V18 starting from a V17 template. I have tried a number of different shadow options. But the image file created by the _Render command is always binarily identical, with, what I would call, sharp shadows.

    There are definitely some issues here. I'll send in an SR later today.

    800 x 600 - 14K
  • When I create a new file right now in V19beta

    Is there a Linux Beta ?

    same here in v19 Mac.
    When trying to Render in Render Window.
    Sharp Shadows works,
    Area Shadows (can't change the value other than 1)
    will render asharp Raytrace Shadow and bring a Red SDK
    exception warning.

    Not much love went into Rendering so far.

  • @Roy Klein Gebbinck
    This issue has been reported already and is currently being addressed. No need to file another support request.

  • As a workaround, you could adjust the value of the DefaultLightShadowBlur system variable. The higher the value, the softer the shadow. There is a hardware limit of 15 to 20 (depending on the graphics card) for the softness. The DefaultLightShadowBlur user preference only controls the on-screen rendering. Results of the Render command currently always have hard shadows.

  • @Louis Verdonck
    Note that there are some GUI issues as well. The non-functioning color dropdown has already been mentioned. And some fields under 'Render Shadow Details' are displayed/hidden in an unexpected manner.

  • Since BricsCAD V18 - AutoCAD 2016 it is no longer possible to set LIGHTINGUNITS to a 0 value ( = do not use lighting units ) - only 1 ( foot-candles ) or 2 ( lux ) can be set. Legacy drawings can have their LIGHTINGUNITS set to 0.
    This produces poor lighting simulation because of the (very) unrealistic linear attenuation of light intensity instead of the inverse square attenuation applied when LightingUnits are used. Besides the unrealistic light intensity, LightingUnits=0 also allowed to set the Sun to any desired color, not very realistic either. When LightingUnits are used, the color of the Sun is set to a fixed value, which matches the experiences described in this post.

  • edited May 2019

    @Roy Klein Gebbinck
    Thank you! it seems that I chose some wrongly positioned prisms, indeed!
    @Knut Hohenberg
    Thanks for the details and the nice shading example!

    Now it seems that shadows work both in the viewing styles (produced directly in the usual main display window), and in the separate rendering window.

    The shadows of the sun seem to never get really sharp (you can set their softness to 0, but they have still slightly soft edges). For good shadows, I'll use Sketchup...

  • Any progress to report on these issues with Sun properties and shadow rendering?

    I am encountering in v20 what may be a related bug: upon executing a 3D modeling operation, such as Slice, the Sun randomly turns off, and gets reset. Sun property Status changes to "Off", and Date changes to 09/21/2011. If I undo the command, it turns back on. When I redo, it turns off again. Happens in different visual styles and whether or not shadows are displayed in viewport.

  • This sounds like a bug to report...

  • Submitted SR102027.

    The Sun-turning-off problem recurs consistently for me with Slice, in all its variations (command line, quad, toolbar, multislice, etc.). I may have wrongly remembered it happening with other commands; it seems to be unaffected by other 3D operations, e.g., boolean, push-pull, dmextrude, that I've tried recently. Curious if others have had a similar problem.

Sign In or Register to comment.
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam