Instancing error

[B.Y.O.B.]

kintuX, can you test the following BlendLuxCore dev versions?

This is the current master (I guess it will crash on your system):
https://www.dropbox.com/s/fooqxxttd0tbf ... l.zip?dl=1

And this is a version that does not do framebuffer updates:
https://www.dropbox.com/s/7brsp8cw46qsk ... R.zip?dl=1
Can you do a final render with this one and see if it also crashes?
It will show no image, it would help me to know if it crashes because of my recent changes to framebuffer import.

[Asticles]

Hi all,

I've tested with your fist build (from last post) and it renders a big instance when it should'nt. Also gives no error.

With the no framebuffer build there is no error also, and no image

[B.Y.O.B.]

I've tested with your fist build (from last post) and it renders a big instance when it should'nt.

I can reproduce it.

So it's not crashing anymore?

[Asticles]

Not crashing for me.

Thanks

[B.Y.O.B.]

Dade: Do you know a good way to make a non-invertible matrix invertible?

My naive approach:

Code: Select all

l = [matrix[0][0], matrix[1][0], matrix[2][0], matrix[3][0],
         matrix[0][1], matrix[1][1], matrix[2][1], matrix[3][1],
         matrix[0][2], matrix[1][2], matrix[2][2], matrix[3][2],
         matrix[0][3], matrix[1][3], matrix[2][3], matrix[3][3]]

    if matrix.determinant() == 0:
        # The matrix is non-invertible. This can happen if e.g. the scale on one axis is 0.
        # Prevent a RuntimeError from LuxCore by adding a small random epsilon.
        
        from random import random
        return [float(i) + (1e-5 + random() * 1e-5) for i in l]

Is this a super stupid idea and will I run into problems with this approach later?
I'm basically adding a random epsilon from the range [1e-5 to (2 * 1e-5)] to each value.

I have a feeling that I only have to do this with the scale components, but I'm not sure.
(Are the scale components the following in LuxCore? (0, 0), (1, 1) and (2, 2)?)

edit: I had a look how Blender solves this problem in its "invert_safe()" method:

Code: Select all

mat[0][0] += eps;
mat[1][1] += eps;
mat[2][2] += eps;
mat[3][3] += eps;

if (UNLIKELY(det = determinant_m4(mat)) == 0.0f) {
	unit_m4(mat);
	det = 1.0f;
}

They use a fixed epsilon of 1e-8 and if the matrix is still not invertible after the added epsilon, they fall back to the identity matrix.

[kintuX]

kintuX, can you test the following BlendLuxCore dev versions?

This is the current master (I guess it will crash on your system):
https://www.dropbox.com/s/fooqxxttd0tbf ... l.zip?dl=1

And this is a version that does not do framebuffer updates:
https://www.dropbox.com/s/7brsp8cw46qsk ... R.zip?dl=1
Can you do a final render with this one and see if it also crashes?
It will show no image, it would help me to know if it crashes because of my recent changes to framebuffer import.

Ok, tested & here are results:

1. The current master
a) Yes, it crashes every time as soon as i start render, but only after engine is switched from CPU PT to OCL PT (even on most simple scene: sun+camera).
b) If i start directly using OCL PT, it starts rendering but crashes after render is force stopped (esc).
c) It also crashes if i only switch the engines couple of times & then want to render (f12) - no matter which engine is chosen.

2. No framebuffer version
CPU PT - it runs but nothing is shown (blank buffer/UV image editor Render result)
OCL PT - same here, nothing shown (blank) - then, after couple of times of stopping it, it just crashed

...

OH Purging Orphan data every time before i start rendering seems to solve crashing issues... what the guess there's something buggy in my system, specifically Blender installation.

Cleared Temp folder, caches, config. preferences & startup... still got the same results.

...

New Blender 2.79a installation with only basic addons (officially supplied) & LuxCore, used old startup.blend:

1. Master OCL Works fine

2. No FrameBuffer
Always blank buffer,
a) Crashes even on an empty scene when switching from Cycles (Purge Orphan data helps),
b) Crashes when stopping CPU render
c) OCL seems fine (except for the blank buffer)


Basically i need to troubleshoot my system first sorry for taking your time & everything

[B.Y.O.B.]

I take it that Cycles (or other renderers) do not crash?
Do you have overclocked components, changed RAM timings, undervolted components or anything else like this which could cause system instability?

You could also try running LuxMark and see if that also crashes.
Also make sure that you have the latest graphics driver.

[kintuX]

I take it that Cycles (or other renderers) do not crash?
Do you have overclocked components, changed RAM timings, undervolted components or anything else like this which could cause system instability?

You could also try running LuxMark and see if that also crashes.
Also make sure that you have the latest graphics driver.

1. No, nothing of the above. Other engines run fine.
2. LuxMark ran fine last i checked.
3. Am not using the latest drivers. Last time i installed (Dec. 2017) one of the cards was left without OCL capability. Will test again with the latest.

But as i wrote, your latest OCL build works, if i purge orphan data before starting a render. Just now tested again & again & again... it's a scene file i posted in Object Motion Blur bug (nothing special). But i also had similar problems before, starting with Blender 2.79aRC i simply wish i could get to the bottom of it...

[Asticles]

Hi all,

I've tested at work and still crashes.

Regards

Edit: I'm downloading latest drivers, just in case.

Edit2:Well, with latest drivers the crash has gone, but I get the big instance, like on the other computer.
Edit3:Sorry, has returned, it seems a bit random.

[B.Y.O.B.]

The big instance is a bug in BlendLuxCore (that I already fixed).

It is caused by the following:
- the dupli object is exported once without any transformation
- This is then passed to a fast LuxCore function that duplicates it a few thousand times
- At last the original, un-transformed dupli object from the first step is deleted

In your case, step 2 fails and the code never reaches step 3.
But as I said, it's already fixed.