ValueError: operands could not be broadcast together with shapes (0,) (3,)

[ttsesm]

Hi Ryan,

In the attached scene I am getting the following error:

Traceback (most recent call last):
  File "/home/ttsesm/Development/blender-2.83.2-linux64/2.83/scripts/addons/vi-suite06/vi_operators.py", line 1007, in invoke
    calcout = li_calc(self, simnode, livisimacc(simnode))
  File "/home/ttsesm/Development/blender-2.83.2-linux64/2.83/scripts/addons/vi-suite06/livi_calc.py", line 122, in li_calc
    bccout = ovp.basiccalcapply(scene, frames, rtcmds, simnode, curres, pfile)
  File "/home/ttsesm/Development/blender-2.83.2-linux64/2.83/scripts/addons/vi-suite06/livi_func.py", line 405, in basiccalcapply
    virradm2 = nsum(xyzirrad * array([0.26, 0.67, 0.065]), axis = 1)
ValueError: operands could not be broadcast together with shapes (0,) (3,) 

Most likely it is related to the scene geometry again but I wanted to report it as a test case.

Also with the last update I am getting the following KeyError message which is not critical though:

Traceback (most recent call last):
  File "/home/ttsesm/Development/blender-2.83.2-linux64/2.83/scripts/addons/vi-suite06/__init__.py", line 217, in d_update
    for d in context.scene.vi_params['viparams']['drivers']:
KeyError: 'bpy_struct[key]: key "viparams" not found'
File "/home/ttsesm/Development/blender-2.83.2-linux64/2.83/scripts/addons/vi-suite06/__init__.py", line 214, in d_update

[rgsouthall]

The key error should disappear once geometry or context have been re-exported. If it doesn't let me know. The file you sent I assume you get the error when running from your script? I get a failure in the script at line 315 as no src module is found.

[ttsesm]

Yes, the keyerror message shows once. Apologies in the file I've attached before I did not set it up correctly. Please try this attachment, if you press the calculate button in Vi Simulate you should get the error.

house.zip

[rgsouthall]

There is too much geometry there to debug as they are all light sensors. Hide objects and then unhide them to track down which object is the problem.

[ttsesm]

Apologies again, the problem seems to be in the ceiling (if I hide it then the simulation seems to work fine).

Find attached a simplified .blend file with only this room.

room_.zip

[rgsouthall]

Yes, the ceiling geometry is particularly nasty. Makes a nice stress test for the Suite though. Face 1 is the problem as is it is almost non-existent and is causing a problem as geometry, not as a light sensor. You can try upping the decimal places for position export in the radpoints routine in livi_export. LiVi Sim now terminates with an error and flags up the problem geometry in the log file. It will be while before I upload it as I have to implement that for all LiVi calculation types and test it.

[rgsouthall]

Just noticed that trying to preview the scene will write the problem geometry to the log file in the form poly__objectnamefaceindex

[ttsesm]

Thanks Ryan.

Yes, the ceiling geometry is particularly nasty. Makes a nice stress test for the Suite though.

Well more or less I have approx. 45K of such scenes that I am planning to process (meanwhile I might get access to even more, hopefully with better geometry), since as I was telling you I am targeting a large scale experimentation. I guess I might get some more nasty geometry cases :-p.

You can try upping the decimal places for position export in the radpoints routine in livi_export.

To be honest, I didn't really understand what you mean with the above.

LiVi Sim now terminates with an error and flags up the problem geometry in the log file. It will be while before I upload it as I have to implement that for all LiVi calculation types and test it.

Well for now, it is not really urgent to have the patch right away since I can skip such scenes. Thus, no worries I can wait until you have it fully functional.