Mantis Bug Tracker
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001172LuxRenderCorepublic2011-11-17 21:492013-02-25 08:41
Reporterpciccone 
Assigned Tojeanphi 
PriorityhighSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformMacintoshOSMac OSOS Version10.6.8
Product Version1.0 
Target Version1.2Fixed in Version1.2 
Summary0001172: When using displacement (loop) with OpenCL, Lux crashes
DescriptionTested this with both bidir and path, the log file shows the subdivision happening, all progress normally until just a moment before updating the framebuffer. At that point Lux crashes. The same scene renders OK with non-OpenCL renderer.
Additional InformationHere is an excerpt from the crash log, under Mac OS X 10.6:


0 liblux.dylib 0x00000001001c89c1 luxrays::QBVHAccel::BuildTree(unsigned int, unsigned int, unsigned int*, luxrays::BBox*, luxrays::Point*, luxrays::BBox const&, luxrays::BBox const&, int, int, int) + 2543
1 liblux.dylib 0x00000001001c95c5 luxrays::QBVHAccel::Init(luxrays::Mesh const*) + 1561
2 liblux.dylib 0x00000001001c7462 luxrays::QBVHAccel::Init(std::deque<luxrays::Mesh*, std::allocator<luxrays::Mesh*> > const&, unsigned int, unsigned int) + 366
3 liblux.dylib 0x00000001001ccb0b luxrays::DataSet::Preprocess() + 679
4 liblux.dylib 0x000000010059d6ff lux::HybridRenderer::PreprocessGeometry(luxrays::Context*, lux::Scene*) + 319
5 liblux.dylib 0x00000001005a05dd lux::HybridSamplerRenderer::Render(lux::Scene*) + 685
6 liblux.dylib 0x00000001004972d4 lux::Context::WorldEnd() + 804
7 liblux.dylib 0x000000010047f3a3 yyparse() + 10915
8 liblux.dylib 0x00000001004866d0 parseFile(char const*) + 160
TagsNo tags attached.
Mercurial Changeset #
Requires Documentation UpdateNo
Requires Exporter Update
Attached Files

- Relationships

-  Notes
(0003246)
J the Ninja (developer)
2011-11-21 14:56

 I can't reproduce with 10.7.2. Do you have another machine with a newer OS X version (10.6.8 or 10.7*) to test with? Possible 10.6.3 has an old opencl driver?
(0003247)
pciccone (developer)
2011-11-21 14:59

 I'm on 10.6.8
(0003248)
J the Ninja (developer)
2011-11-21 15:04

 It says 10.6.3 in the report?
(0003249)
pciccone (developer)
2011-11-21 15:16

 My mistake but the description mentions 10.6.8
(0003250)
J the Ninja (developer)
2011-11-21 15:20

 I updated the info.

Still not sure why I can't reproduce it on my machine, fixed in the OpenCL changes in 10.7, perhaps? Does this happen with ANY loop-sudivision shape that has a displacement map applied?
(0003251)
pciccone (developer)
2011-11-21 15:25

 I don't remember, I'll have to test it again.
(0003286)
pciccone (developer)
2012-01-11 21:58

 This has been confirmed by many people on both Mac OS and Windows
(0003361)
J the Ninja (developer)
2012-03-12 01:13

 I still can't reproduce it. Can you post a scene file that reproduces the crash? Those are always a time saver compared to trying to reproduce a crash-scene manually.

Does Reality still use the loopsubdiv primitive or has it switched to the subdivscheme param with plymesh? Hybrid is kinda picky about what primitives it will use. It doesn't like microdisplacement and spheres for that reason, maybe the loopsubdiv shape causes issues too? I tried making a plymesh shape that used loop via the subdivscheme param in LuxBlend25, and it renders fine with and without displacement.
(0003364)
Dade (developer)
2012-03-23 08:36

 J the Ninja, I have recently noted (while working on SQBVH) that plymesh select the kind of accelerator according the number of polygons in the mesh:

        // Select best acceleration structure
    MeshAccelType concreteAccelType = accelType;
    if (accelType == ACCEL_AUTO) {
        if (refinedPrims.size() <= 250000)
            concreteAccelType = ACCEL_NONE;
        else if (refinedPrims.size() <= 500000)
            concreteAccelType = ACCEL_KDTREE;
        else
            concreteAccelType = ACCEL_QBVH;
    }

This may be one of the reason sometime the problem happens and sometime it doesn't.

Anyway, if someone can provide a test scene showing the problem I can look for a fix.
(0003372)
pciccone (developer)
2012-04-11 21:28

 It's becoming harder to reproduce it. I have a case but it's with a commercial product so I can't distribute it. All my attempts to reproduce the problem with standard primitives, with the March 4th build, failed.
I tested the latest build, April 6th, and it's still crashing.
(0003373)
pciccone (developer)
2012-04-11 21:44

 Jason, to answer your question, Reality uses the subdivscheme parameter.
(0003612)
Lord Crc (administrator)
2012-09-01 04:30

 It could be that the loop subdivision produces so fine meshes that the normal computation code runs into numerical issues and produces infinite values for one or more normals. The infinities then "poison" then vertex positions in the displacement routine. I've seen this happen on some meshes.

The infinities then could cause qbvh to barf I guess.
(0003613)
jeanphi (administrator)
2012-09-01 09:04

 There's an even worse issue in that it seems that the Tesselate is called on non refined meshes and that might not be compatible with subdivided meshes because the original mesh gets updated.
LuxRays QBVH code is quite similar to LuxRender QBVH code, so there should be issues in CPU mode too.
(0003621)
jeanphi (administrator)
2012-09-02 12:11

 Postponing the issue since it seems to work on most cases. Without access to a tst scene it might be extremely difficult to fix the issue.
(0003835)
jeanphi (administrator)
2013-02-16 09:10

 Is it still an issue?
(0003840)
pciccone (developer)
2013-02-22 08:04

 No, it has been resolved in Reality 3. This report can be closed. Thank you.

- Issue History
Date Modified Username Field Change
2011-11-17 21:49 pciccone New Issue
2011-11-17 21:49 pciccone Status new => assigned
2011-11-17 21:49 pciccone Assigned To => Dade
2011-11-21 14:56 J the Ninja Note Added: 0003246
2011-11-21 14:59 pciccone Note Added: 0003247
2011-11-21 15:04 J the Ninja Note Added: 0003248
2011-11-21 15:16 pciccone Note Added: 0003249
2011-11-21 15:19 J the Ninja OS Version 10.6.3 => 10.6.8
2011-11-21 15:20 J the Ninja Note Added: 0003250
2011-11-21 15:25 pciccone Note Added: 0003251
2012-01-11 21:58 pciccone Note Added: 0003286
2012-03-12 01:13 J the Ninja Note Added: 0003361
2012-03-23 08:36 Dade Note Added: 0003364
2012-04-11 21:28 pciccone Note Added: 0003372
2012-04-11 21:44 pciccone Note Added: 0003373
2012-08-31 13:43 jeanphi Assigned To Dade => jeanphi
2012-09-01 04:30 Lord Crc Note Added: 0003612
2012-09-01 09:04 jeanphi Note Added: 0003613
2012-09-02 12:11 jeanphi Note Added: 0003621
2012-09-02 12:11 jeanphi Target Version 1.0 =>
2013-02-16 09:10 jeanphi Note Added: 0003835
2013-02-16 09:10 jeanphi Status assigned => feedback
2013-02-22 08:04 pciccone Note Added: 0003840
2013-02-22 08:04 pciccone Status feedback => assigned
2013-02-25 05:22 jeanphi Target Version => 1.3
2013-02-25 08:41 jeanphi Status assigned => resolved
2013-02-25 08:41 jeanphi Fixed in Version => 1.2
2013-02-25 08:41 jeanphi Resolution open => fixed
2013-02-25 08:41 jeanphi Target Version 1.3 => 1.2
2013-02-25 08:41 jeanphi Status resolved => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker