Open jzwar opened 1 year ago
It seems that the function eval
in make_showable
keeps track of the results. I think that the key words are just passt without checks to the vedo interface. Maybe we should not use vedo-keywords as show_options. Use spline_c
/ spline_color
/ 'base_color` instead? The keywords are not really consistent. We use full snake-case for some keys but abbreviations for others.
If you use show_options
to set options, it will show you as expected. To answer # Uses this instead : why?
- as **kwargs
are passed to gus.show
, it overwrites all the options that's applicable to sampled objects. c
is a very common option. We can stop processing show_options from kwargs to avoid confusion.
I know that c
is applicable to points and meshes as well, which is exactly why I think we should rename the spline color options c
, alpha
, etc. to unique splinepy option names. Having duplicates is confusing imo, or we have to set vedo options more explicitly, with something like 'vedo_options=dict`
That's a problem related to using the workflow gus.show(..., **show_options)
. You can maybe edit that part
This may be - "this is a feature not a bug" However, I see that we may want some lazy-but-accurate show_options options. Some thoughts:
spp_
. We will have to wrap gus.show
vedo.Plotter
and extend functions for our use. This will allow us to write easier interactive miniapps
If colors are set differently for the knots and control points via keyword arguments, these will be ignored if the color
c
is stated. Here is an example:Results in: