RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Simon Windmill » Mon, 11 Jul 2005 01:20:37 GMT

I'm coming back to an old project after a couple months' absence, and
when rendering directly with 3Delight from my code I'm getting a crash
in 3delight.dll - "Float divide by zero" - whenever geometry
(PointsPolygons) is rendered. If I change the code to write out to .rib
and render that with renderdl, it works just fine.

Has anybody ever seen anything like this?

Simon.

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Olivier3001 » Fri, 15 Jul 2005 23:58:33 GMT


Do you see the same behavior if you output binary RIB? Ascii output
still has minor roundoff errors which could cause a problem like this
to go away. If you can reproduce the problem with a RIB then please
send a bug report. If you want, you can also send a small amount of
code to reproduce the problem.

Olivier Paquet
------
3Delight development team

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Rick LaMont » Sat, 16 Jul 2005 05:31:13 GMT


I think you misunderstood the report. Simon's problem goes away once he
uses RIB. It only happens when he uses the C bindings to the rendering
library (not the RIB client library).


Rick LaMont
Dot C Software, Inc.
http://www.dotcsw.com/

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Olivier3001 » Sat, 16 Jul 2005 11:17:11 GMT


I understood it quite well. The point of my reply is that "C code" ->
"ASCII RIB" -> "rendering" will not always feed exactly the same values
to the renderer as "C Code" -> "rendering" (this is something in need
of fixing). It could be what's causing the problem to go away with RIB.
Using a binary RIB should yield the exact same values and narrow down
the possibilities.

Also if it turns out the bug exists with a binary RIB, it's easier to
send than a piece of code. If it doesn't, then there is a greater
chance that the bug is somehow in the code (perhaps memory corruption).

Olivier

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Rick LaMont » Wed, 20 Jul 2005 11:49:33 GMT


I see. Now your first post makes perfect sense.


The RIB client library in PRMan 3.7 makes some roundoff errors when
producing *binary* RIB. For example, 0.03126525 becomes 0.03125 due
to fixed point representation.

Binary RIB as specified is capable of preserving precision. It even
has an encoding for double precision IEEE floating point values. To
me, that seems like overkill whenever the renderer that eats the RIB
defines RtFloat as single precision.

Does anyone have use for double precision binary RIB?


Rick LaMont
Dot C Software, Inc.
http://www.dotcsw.com/

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Olivier3001 » Wed, 20 Jul 2005 21:26:23 GMT


Wow... that's pretty unimpressive. And here I was worrying about our
ascii output sometimes loosing a bit of precision hehe. I still wish
printf had a 'full precision but no more' format.


Well, I don't think anything in the spec says you can't have a double
as your RtFloat so it makes sense that the binary format is capable of
encoding double values as well. Of course nobody would do that right
now because of the memory use but it may come someday.

Olivier

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by dansspam2@yahoo.com » Mon, 25 Jul 2005 10:22:55 GMT

I once came across a detailed paper on lossless ASCII<->float
conversion. It turns out to be possible, but highly non-trivial. I kind
of doubt most sprintf() implementations actually get all the corner
cases right.

I tried looking for the paper but now I can't find a link to it. I
think it was written pre-1990.

Regards,
Dan

RenderMan & RISpec >> "Float divide by zero" error in 3Delight?

by Rick LaMont » Wed, 27 Jul 2005 03:26:14 GMT


You mean these?

William D Clinger, "How to Read Floating-Point Numbers
Accurately". SIGPLAN notices 25, 6 (June 1990), 92-101.

Guy L Steele Jr and Jon L White, "How to Print Floating-Point
Numbers Accurately". SIGPLAN notices 25, 6 (June 1990), 112-126.

There's also this newer one:

Robert G Burger and R. Kent Dybvig, "Printing Floating-Point
Numbers Quickly and Accurately". SIGPLAN 1996, 108-116.


Rick LaMont
Dot C Software, Inc.
http://www.dotcsw.com/

Similar Threads

1. 'Float' followed by 'float' compile error?

I get a strange compile error in the D3DXMATRIX constructor:

c:\dx90sdk\include\d3dx9math.inl(749) : error C2628: 'FLOAT' followed by 
'float' is illegal (did you forget a ';'?)
c:\dx90sdk\include\d3dx9math.inl(754) : error C2062: type 'float' unexpected

Does anybody know what would cause this?

Here is the area that it is complaining about in d3dx9math.inl and the 
function directly above it:

D3DXINLINE
D3DXMATRIX::D3DXMATRIX( CONST D3DXFLOAT16* pf )
{
#ifdef D3DX_DEBUG
    if(!pf)
        return;
#endif

    D3DXFloat16To32Array(&_11, pf, 16);
}

D3DXINLINE
D3DXMATRIX::D3DXMATRIX( FLOAT f11, FLOAT f12, FLOAT f13, FLOAT f14,
                        FLOAT f21, FLOAT f22, FLOAT f23, FLOAT f24,
                        FLOAT f31, FLOAT f32, FLOAT f33, FLOAT f34,
                        FLOAT f41, FLOAT f42, FLOAT f43, FLOAT f44 )
{

I am using the D3DXMATRIXA16 class, I don't know if that matters or not.

Thanks!

2. Negative floating point zeros

3. HELP: Winding (non-zero) polygon fill using floating point

Imagine I've got a self-intersecting polygon. When I draw and fill this
polygon using the "Winding" or "non-zero" rule, I get some areas filled in,
and others not filled in.

Is there anyway to get the floating point co-ordinates of the vertices on
the boundaries between "filled" and "non-filled" regions?

Any algorithms or links to algorithms would be useful.

Cheers





4. \includegraphics causing "treated as zero" error

5. ANN: 3Delight 9.0 and 3Delight For Maya 5.0

Hello everyone,

3Delight 9.0.0 and 3Delight For Maya 5.0 are available for download.
Here is a list of the most important improvements:

New Unlimited-threads License
  * A new unlimited-threads license is now available for both the
    3Delight standalone renderer and the 3Delight for Maya plug-in.
    Clients that purchased the 8-thread license (and under yearly
    support) are automatically upgraded to unlimited-threads. The
    8-thread license will no longer be available, but the 4-threads
and
    2-threads will continue to be available at a reduced pricing.

3Delight For Maya
  * Introducing RIB Fragments: a user-friendly and flexible way of
    creating and managing RIB archives. This feature is useful to
    accelerate re-renders.
  * The display drivers UI has been improved and simplified making it
    easier to manage and visualize output variables (AOVs). "Primary
    Displays" and "Secondary Displays" have been collapsed into the
    same UI.
  * Major performance improvements to the 3Delight Relationship Editor
    which make it responsive even with very large scenes.
  * Improved UI in the 3Delight Relationship Editor by using
    distinctive icons for different shaders and attributes.
  * Added support for many useful Hypershade nodes, most importantly:
    misss shaders, car paint, metallic paint, glossy reflection and
    glossy refraction.
  * Scene parsing optimizations reduce RIB output time by 20%.
  * It is now possible to render Shave and a Haircut nodes without
    loading the 3dfmShave plug-in: 3Delight for Maya automatically
uses
    Shave plug-in's RIB export function in that case.
  * Maya sprite particles can now be rendered as "volumes" for correct
    shadowing.
  * Maya fluids implementation enters a beta stage. All current
    limitations are listed in the user's manual in the Rendering
    Guidelines chapter.
  * Added Maya 2010 support and dropped Maya 8.0 support.

3Delight Features
  * Introducing multi-camera rendering. This features enables the
    output of many camera views from a single render. This
    functionality is especially useful for stereo rendering as it
saves
    rendering time.
  * Improvements to point-based occlusion quality: concave corners are
    rendered more accurately.
  * The subsurface shadeop can proceed from a point-cloud file. This
    can save a potentially costly pre-processing step when rendering
    sequences.
  * Billboard particles can now be rendered with a "thickness" for
    correct shadow casting.
  * Network caching, a feature unique to 3Delight, is now available on
    Windows systems.
  * Added detailed memory statistics to 3Delight to better track
memory
    usage.

3Delight Performance
  * Improved performance of occlusion() and indirectdiffuse() shadeops
    when rendering dense meshes. Speedups can reach 200%.
  * Improved multi-threading performance on scenes containing
    procedural geometry (such as delayed read archives). Procedurals
    are now allowed to execute in parallel which can lead to speed
    improvements linear to the number of threads used.
  * Accelerated point-based occlusion as it nows respected the
    "irradiance shadingrate". Speedups with default settings are in
the
    200%-300% range. Also improved quality of the occlusion in concave
    corners.
  * Improved multi-threading performance and memory consumption of
    subsurface scattering algorithm.
  * Improved deep shadow map creation performance. On large shadow
    maps, performance increases linearly with the number of cores.
    Temporary disk space usage during DSM creation has been reduced
    three-folds.
  * A new memory allocation scheme in the ray-tracer significantly
    lowers memory consumption when rendering object: only one object
    instance is kept in memory at any time. This feature is enabled
    through a special variable.
  * Improved point-cloud loading time. This has a positive performance
    impact on effects such as point-based occlusion and color
bleeding.

Shader Compiler
  * RSL 2.0 improvements including resizeable arrays, better supports
    for shader classes and more efficient execution.

Pipeline & API
  * Introducing the "VolumeTracer" API. This RSL plug-in allows user
to
    easily write volume renderers.
  * The "Sx" shader evaluation API is now embedded with the 3Delight
    library (takes a single 3Delight license when used).
  * Added "Implicit Field" plug-in support (extension to the
`RiBlobby'
    primitive).
  * Display drivers can now access 3Delight's deep frame buffer which
    provides the list of visible surfaces for each pixel sample.
  * Added new entries to the Ptc API and fixed compatibility issues.
  * `RiNuCurves' now support vertex normals.

Thank you,

-- aghiles
www.3delight.com

6. Dealing with floating point errors

7. Please help with: PointsPolygons [nverts ] [verts ][facevarying float s][facevarying float t]

8. Why clip before perspective divide?!?!?!