scan API restructure about blensor HOT 5 CLOSED

I do agree that the parameters with their default parameters are messy, this is "historical" since the whole thing emerged from a single python script to simulate the velodyne.

Getting rid of this is definitely a worthy task, but you are right. one reason for not passing the obj itself is the fact that this code can be called from other python scripts that just use the active camera as the scanner.

Using some kind of inheritance for sensor parameters however seems to be very useful

Proposal

Create a Sensor class that combines the default parameters and has a constructor that takes a Camera object and copies the relevant data into the sensor object.
Derive all sensors and extend the parameters (change the default values) accordingly.

class Sensor(object):
  max_distance = 120
  def __init__(self, blender_object):
    self.max_distance = blender_object.max_distance

class Velodyne(Sensor):
  rotation_speed = 15
  angle_resolution = 0.1728
  ...
  ...
  def __init__(self, blender_object):
    Sensor.__init__(self, blender_object)
    self.rotation_speed = blender_object.rotation_speed
    self.angle_resolution = blender_object.angle_resolution
...
...
...

sensor = Velodyne(obj)

scan_advanced(sensor,'test.evd', Matrix())

from blensor.

I think copying from obj to sensor is redundant because if you just want to use the active camera it will already have the default values set, thanks to the addProperties(cType) call. Restricting default values to the one place (that addProperties method) would be cleaner, and removes any potential issues with forgetting to copy from obj to sensor if we add a new property.

Using your proposal, if you wished to create a "sensor" without modifying the active camera, you could do:

 sensor = Velodyne()
 sensor.max_dist = 100
 scan_advanced(sensor, ...)

But with mine the only difference would be

 sensor = bpy.data.objects.new('temp', None)
 sensor.max_dist = 100
 scan_advanced(sensor, ...)

Perhaps I'll code it up and if you find any use cases that need the separate Sensor classes, it'd be trivial to add in. The added advantage of my method is that the other properties already defined on sensor (such as object_matrix, etc.) are also accessible

from blensor.

Hmm there could theoretically be a scenario where the sensor objects store information that is not stored as blender properties.

For example:
The laser configurations should be stored in the sensor object since we could have more than one sensor of the same type. Some properties may be loaded from a file instead of exposing them in the blender menu.

If a sensor is it's own object it could have save/load methods to store the sensor configuration in a file.

Thinking further into the future i think the addProperties should be done by the Sensor object too. That way the default values would only be held in one place.

But we can go with your approach for now and check if the requirements i mentioned are really an issue or not

from blensor.

Well currently laser configurations are stored in each object, and that would remain the case. So different sensors could be represented by different cameras in the scene. If you wanted to be able to load parameters from a file into a blender object, it'd be easy to write an operator to do it.

As far as further into the future goes, I think it makes sense for the Sensor object to be a subclass of bpy.types.object (or just remain an object with extra properties like it is now). That way blender will save it for you automatically, and also allow cool things like keyframe animation of parameters.

I'll get started on the refactoring and see what issues I run into on the way :)

from blensor.

I know, storing the sensor properties in the blender file greatly simplifies the distribution of scans without having to send the whole scan result.

Well then it's decided. :)

from blensor.