Andras Lasso

Thanks a lot! Both planned tasks would be really nice. Maybe instead of an additional conversion parameter, we could have multiple values for endcapping (0=none, 1=smooth, 2=straight).

Adding dummy nodes is not very clean and makes it more difficult to synchronize the visibility of the isodose surfaces and the color legend. Instead, a nicer solution would be...

> The method `int GetDoseUnitsFromString(const char *)` has already been added: That's good, but for backward compatibility `GetDoseUnitsFromString` should recognize the old values (`0`, `1`, and `-1`) and not just...

OK to merge for me, too. I would merge it, but, as @cpinter noted, there are conflicts that @MichaelColonel would need to resolve by rebasing on latest master.

We still have the error message: "This branch cannot be rebased due to conflicts" - Pull from SlicerRt:master - Rebase - Force-push to MichaelColonel:isodose-cl

It is good now, merged. Thanks a lot for your contribution!

As an experiment, you can just put the volume rendering actor and mapper directly in the VTK renderer (see helpful code snippets [here](https://slicer.readthedocs.io/en/latest/developer_guide/script_repository.html#access-vtk-views-renderers-and-cameras)). The most important thing to try if...

To solve the original problem of having many nodes in the scene, a much better solution could be to show isodose surfaces and lines using a single segmentation node.

DICOM standard requires reference to the CT image. We need the CT image geometry to interpret the RT structure set (otherwise we can only guess the slice spacing).

@Namng1210 Have you segmented an MRI image and tried to import that into Eclipse?