LuxRender v1.3RC2

News & Announcements regarding releases, features, exporters and project coordination.

Moderators: Dade, coordinators

Re: LuxRender v1.3RC2

Postby Harvester » Tue Sep 17, 2013 5:19 am

Thank you Lord CRC.

I followed your instructions and duly modified the preview_scene.py file, then I restarted Blender and now it no longer crashes but, as you pointed out, the Mat/Tex preview is now completely black.

I appreciate very much all the work that you and your colleagues are doing to build one of the most robust and stable rendering engine available.

Cheers!
Harvester
 
Posts: 20
Joined: Fri May 04, 2012 8:09 am

Re: LuxRender v1.3RC2

Postby Lord Crc » Tue Sep 17, 2013 5:39 am

Harvester wrote:I followed your instructions and duly modified the preview_scene.py file, then I restarted Blender and now it no longer crashes but, as you pointed out, the Mat/Tex preview is now completely black.


Hmm it shouldn't be black, at least for the default sphere one... It just shouldn't have a smooth backdrop.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: LuxRender v1.3RC2

Postby Lord Crc » Tue Sep 17, 2013 5:41 am

jeanphi wrote:That's quite bad, and I thought that loopsubdiv issues were behind us...


I guess it's an uninitialized pointer. IRCC memory is zero-initialized on osx/linux, but that is not the case with vc++.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: LuxRender v1.3RC2

Postby Harvester » Tue Sep 17, 2013 7:35 am

Sorry Lord CRC, it's my fault. I thought that commenting out line 320 would have been fine but I was obviously wrong. So, I deleted it and the preview now works fine, apart from the backdrop's smoothness as you forecasted.

Thank you.
Harvester
 
Posts: 20
Joined: Fri May 04, 2012 8:09 am

Re: LuxRender v1.3RC2

Postby cwichura » Tue Sep 17, 2013 1:56 pm

Lord Crc wrote:
jeanphi wrote:That's quite bad, and I thought that loopsubdiv issues were behind us...


I guess it's an uninitialized pointer. IRCC memory is zero-initialized on osx/linux, but that is not the case with vc++.

Windows memory management always zeros pages, so newly allocated memory will be zero-initialized. Unless VC++ is using an internal memory manager within the app and re-using freed memory not given back to the OS for later allocation and not zeroing that?
cwichura
 
Posts: 509
Joined: Sun Feb 12, 2012 11:31 pm

Re: LuxRender v1.3RC2

Postby Lord Crc » Tue Sep 17, 2013 3:18 pm

cwichura wrote:Windows memory management always zeros pages, so newly allocated memory will be zero-initialized. Unless VC++ is using an internal memory manager within the app and re-using freed memory not given back to the OS for later allocation and not zeroing that?


It's my understanding that it does not use the Windows allocator directly, as it's not terribly efficient for "random size" allocations. We've had crashes like this before, where it all works fine on Linux/OSX as they initialize memory always, it seems.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

Re: LuxRender v1.3RC2

Postby danstermeister » Tue Sep 17, 2013 4:24 pm

jeanphi wrote:Hi,

That's quite bad, and I thought that loopsubdiv issues were behind us...

Jeanphi


Ugh, I'm sorry to hear that man. I'm using it a lot, so if there's any corner-case stuff you want tested, let me know (Win8-64 on AMD8120 8GB-RAM, Radeon6850 and GTX 660ti, Blender 2.68a, r58537).

Here's all the quirk I can describe currently in case something sparks a clue:
    I tried to make the line changes themselves before using the attached file but it didn't work- the preview screen was simply black (but it did not crash). I work in Perl so I don't -think- I fat-fingered anything. Just thought I'd mention it in case there's more diff between the suggested line changes and the actual attached file.
    I didn't take notice prior to this, but the preview (working with the code patch attachment) renders strictly with my CPU and not my video cards, even though I'm set for SLG on the GPUs when rendering (and the actual rendering itself is utilizing the CPU and GPU's fine). I thought previously that the preview window did utilize the GPU's but I can't remember.
Thanks for your work on this. Seriously. It doesn't make me a dime, but it makes me super-happy. If there's anything I can do in return, please lemme know :)
User avatar
danstermeister
Developer
 
Posts: 154
Joined: Thu Aug 15, 2013 5:29 pm
Location: Boynton Beach, FL

Re: LuxRender v1.3RC2

Postby Piita » Sat Sep 21, 2013 3:55 am

I had the same material preview crash here. RC1 luxblend worked fine but RC2 crashes. Using the temporary fix now and it works fine. Yes!! :D
I can confirm that changing the code lines results in black material preview, but Lord's attached zip makes it work. Using win7 x64, blender 2.68a
User avatar
Piita
 
Posts: 611
Joined: Sat Aug 06, 2011 2:09 pm
Location: Finland

Re: LuxRender v1.3RC2

Postby jeanphi » Sun Sep 22, 2013 1:59 pm

Hi,

Lord Crc, since I can't reproduce the issue, could you try the following patch and see if it helps and triggers the message?
Code: Select all
diff -r 3b7713c70302 shapes/loopsubdiv.cpp
--- a/shapes/loopsubdiv.cpp   Thu Sep 12 21:37:39 2013 +0200
+++ b/shapes/loopsubdiv.cpp   Sun Sep 22 20:57:51 2013 +0200
@@ -278,6 +278,10 @@
             face->children[k]->v[k] = face->v[k]->child;
             // Compute odd vertex on _k_th edge
             SDVertex *v0 = face->v[k], *v1 = face->v[NEXT(k)];
+            if (!v0 || !v1) {
+               SHAPE_LOG(name, LUX_ERROR, LUX_CONSISTENCY) << "Invalid vertex data while subdividing mesh, aborting subdivision";
+               return boost::shared_ptr<LoopSubdiv::SubdivResult>();
+            }
             SDEdge edge(v0, v1);
             map<SDEdge, SDVertex*>::iterator itEdge = edgeVerts.find(edge);
             SDVertex *vert;


Jeanphi
jeanphi
Developer
 
Posts: 7943
Joined: Mon Jan 14, 2008 7:21 am

Re: LuxRender v1.3RC2

Postby Lord Crc » Mon Sep 23, 2013 5:48 am

jeanphi wrote:Lord Crc, since I can't reproduce the issue, could you try the following patch and see if it helps and triggers the message?


It seems to only happen with open manifolds (ie a plane) and only during release mode, not debug mode, so pretty sure it's uninitialized memory.

I'll do some more digging tonight.
May contain traces of nuts.
User avatar
Lord Crc
Developer
 
Posts: 5032
Joined: Sat Nov 17, 2007 2:10 pm

PreviousNext

Return to News & Announcements

Who is online

Users browsing this forum: No registered users and 1 guest