LuxCoreRender Forums

Posted: **Thu Feb 08, 2018 8:08 am**

jensverwiebe wrote: Thu Feb 08, 2018 12:24 am The problem seems luxcore exporter does not read blender packed images right now.

No, packed images are supported: https://github.com/LuxCoreRender/BlendL ... t/image.py
However they are saved without extension, maybe OIIO needs the extension to determine file type?

edit: they are now saved with extension, can you test again?

Posted: **Thu Feb 08, 2018 10:09 am**

B.Y.O.B. wrote: Thu Feb 08, 2018 8:08 am However they are saved without extension, maybe OIIO needs the extension to determine file type?

Yup.

Posted: **Thu Feb 08, 2018 11:43 am**

kintuX wrote: Thu Feb 08, 2018 1:08 am
Dade wrote: Wed Feb 07, 2018 9:30 pm
kintuX wrote: Wed Feb 07, 2018 8:53 pm Tried to do compilation time comparison:
- v2.78for Blender 2.78c & LuxCoreSDK 1.7: 34693ms
- v2.79 same scene, nodes redone for 2.79a RC LuxCoreAlpha3: previously took ~20min, now gives an error:
Is that 34secs Vs. 20mins ?
Yup, that's right (2GPUs - so around the same times as jens got)

@ jensverwiebe
basically i just redid the shading/nodes for 2.79 with Luxcore2beta, since old ones don't get through
had noticed problems with packed textures before, but didn't pay any further attention, here i had textures unpacked (packed it for the sake of posting) had also similar problem with relative texture paths when they were called from python (on Windows)
+ the strangest thing is that something inside this scene bothers Blender 2.79a RC even without Lux (any action then Undo & crash)
...
will get through the full posts tomorrow, refreshed - am starting to lose vision & thought flow...

@ kintuX
Jep, packing textures is the smart way to go normally, as you might have seen, the issue is allready identified ( cached tex had no extension )
and fixed in exporter git now. I don't have your secret files anymore, can you pls retest your file ? ( my simple test works now )
In the past we had probs with relative pathes ( aside from // aka relative to blendfile ). Afaik thats an alltime problem. One should take a look
how rel_path is resolved. I saw strange sideeffects having files on different disks. ( my guess: exporters do not know about blend location )
Have still to investigate undo problems, got late last night . ( initially found no problem yet )

I will go to check especially procedural textures again. Afaik at some point of luxcore dev 1.7, compilation times exceeded which
could have todo with changed inlining behaviour of NV cl ( NV switched to an llvm based compiler ).

Jens

Posted: **Thu Feb 08, 2018 12:26 pm**

Procedurals onn NV:

Started with a musgrave and compiletimes were neglectible.
Unfortunately the final render crashed at the end (reproducable each run, native, ocl seems to work):

Code: Select all

# Blender 2.79 (sub 0), Commit date: 2018-02-06 14:37, Hash e5917d6
bpy.data.node_groups["Material.003"].nodes["Material Output"].active = True  # Property
bpy.ops.node.select(mouse_x=970, mouse_y=198, extend=False)  # Operator
bpy.ops.node.translate_attach(TRANSFORM_OT_translate={"value":(200.976, 47.0212, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "texture_space":False, "remove_on_cancel":False, "release_confirm":True, "use_accurate":False}, NODE_OT_attach={}, NODE_OT_insert_offset={})  # Operator
bpy.ops.node.select(mouse_x=637, mouse_y=302, extend=False)  # Operator
bpy.ops.node.translate_attach(TRANSFORM_OT_translate={"value":(257.773, -22.9639, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "texture_space":False, "remove_on_cancel":False, "release_confirm":True, "use_accurate":False}, NODE_OT_attach={}, NODE_OT_insert_offset={})  # Operator
bpy.ops.node.select(mouse_x=252, mouse_y=410, extend=False)  # Operator
bpy.ops.node.translate_attach(TRANSFORM_OT_translate={"value":(211.898, -10.9352, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "texture_space":False, "remove_on_cancel":False, "release_confirm":True, "use_accurate":False}, NODE_OT_attach={}, NODE_OT_insert_offset={})  # Operator
bpy.ops.node.select(mouse_x=381, mouse_y=393, extend=False)  # Operator
bpy.ops.node.translate_attach(TRANSFORM_OT_translate={"value":(-49.1517, 129.035, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "texture_space":False, "remove_on_cancel":False, "release_confirm":True, "use_accurate":False}, NODE_OT_attach={}, NODE_OT_insert_offset={})  # Operator
bpy.ops.node.add_node(use_transform=True, type="LuxCoreNodeTexBlenderMusgrave")  # Operator
bpy.ops.node.translate_attach_remove_on_cancel(TRANSFORM_OT_translate={"value":(-172.577, 370.702, 0), "constraint_axis":(False, False, False), "constraint_orientation":'GLOBAL', "mirror":False, "proportional":'DISABLED', "proportional_edit_falloff":'SMOOTH', "proportional_size":1, "snap":False, "snap_target":'CLOSEST', "snap_point":(0, 0, 0), "snap_align":False, "snap_normal":(0, 0, 0), "gpencil_strokes":False, "texture_space":False, "remove_on_cancel":True, "release_confirm":True, "use_accurate":False}, NODE_OT_attach={}, NODE_OT_insert_offset={})  # Operator
bpy.ops.node.link(detach=False)  # Operator
Traceback (most recent call last):
  File "/home/jensverwiebe/.config/blender/2.79/scripts/addons/BlendLuxCore/engine/__init__.py", line 237, in view_draw
    self._framebuffer.draw(region_size, view_camera_offset, view_camera_zoom, self, context)
ReferenceError: StructRNA of type LuxCoreRenderEngine has been removed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/jensverwiebe/.config/blender/2.79/scripts/addons/BlendLuxCore/engine/__init__.py", line 259, in view_draw
    del self._session
ReferenceError: StructRNA of type LuxCoreRenderEngine has been removed

location: <unknown location>:-1
  # Error

# backtrace
/media/Workdata3/Development/blender_git/blender-v2.79a-release_build/blender_blender-v2.79a-release/blender(BLI_system_backtrace+0x1d) [0x1a5027d]
/media/Workdata3/Development/blender_git/blender-v2.79a-release_build/blender_blender-v2.79a-release/blender() [0x1042d98]
/lib/x86_64-linux-gnu/libc.so.6(+0x36cb0) [0x7f2198434cb0]

Edit: native crashes all the time, opencl works.
Native works if i do an opencl render beforehand sometimes.
I think there is something fishy with the convergence test / ocl film )
Another observation: since convergence test, the stats progresbar behaves odd, jumps too 100% and the fall back to 0% forever.

Posted: **Thu Feb 08, 2018 1:23 pm**

I found the reason for the crasher in final native render:
I have typical disabled my intel opencl.icd, reenabling made the crash gone.
So this crash should also occure for ppl which not even have installed intel ocl but
using an cl enabled luxcore2 !

If there should be a fallback to native film computing could be worth a discussion.

Jens

Posted: **Thu Feb 08, 2018 6:58 pm**

Just tested the scene with packed textures again, using new BlendLuxCore alpha4 (on win7) & i receive an error:

Code: Select all

Error opening image file : C:\Users\py\AppData\Local\Temp\tmpvkipr6yy.dds (error = OpenImageIO could not open "C:\Users\py\AppData\Local\Temp\tmpvkipr6yy.dds" as dds: Read error
Read error)

Textures in Temp folder now have proper extensions but are all 0 b in size

With unpacked textures scene works great, compiling also

Posted: **Thu Feb 08, 2018 7:06 pm**

Possible win specific issue ? Path slash/backslash thingie ?
How is the tempfile written btw: oiio specs say .dds can only be read.
This should be examined by a windows dev.

Jens

Posted: **Thu Feb 08, 2018 7:20 pm**

jensverwiebe wrote: Thu Feb 08, 2018 7:06 pm How is the tempfile written btw: oiio specs say .dds can only be read.

You can see that in the file I linked earlier in the thread: https://github.com/LuxCoreRender/BlendL ... t/image.py
We use Blender's save() method of the Image class: https://github.com/LuxCoreRender/BlendL ... age.py#L28

Posted: **Thu Feb 08, 2018 7:34 pm**

B.Y.O.B. wrote: Thu Feb 08, 2018 7:20 pm
jensverwiebe wrote: Thu Feb 08, 2018 7:06 pm How is the tempfile written btw: oiio specs say .dds can only be read.
You can see that in the file I linked earlier in the thread: https://github.com/LuxCoreRender/BlendL ... t/image.py
We use Blender's save() method of the Image class: https://github.com/LuxCoreRender/BlendL ... age.py#L28

Imho old lux did write the tempfiles always as png or hdr and remapped.
Remember our discussion when i wanted hdri cached as exr ? ( was also png )
Classic part of this stuff was : https://bitbucket.org/luxrender/luxblen ... 8b09134df3
Don't remenber the luxcore commit. Take into account an exr or hdr should be cached as exr to avoid loss in dynamic.
All other can be scene.render.image_settings.file_format simply or .png in my behalf.

OIIO 1.8: ( we are on 1.3.14 )

DDS (Direct Draw Surface) is an image file format designed by Microsoft for use in Direct3D
graphics. DDS files use the extension .dds.
DDS is an awful format, with several compression modes that are all so lossy as to be
completely useless for high-end graphics. Nevertheless, they are widely used in games and
graphics hardware directly supports these compression modes. Alas.
OpenImageIO currently only supports reading DDS files, not writing them.

Posted: **Thu Feb 08, 2018 7:47 pm**

OK, taking notice... knowing this, makes me feel much better

TYVM for everything

LuxCoreRender Forums

Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?

Re: Compiling rules: when should it happen?