Graphics3d breaking changes#1492
Graphics3d breaking changes#1492TiagoCavalcante wants to merge 4 commits intomathics:masterfrom TiagoCavalcante:graphics3d-breaking-changes
Conversation
TiagoCavalcante
commented
Jul 21, 2021
TiagoCavalcante
commented
| "ticks": ticks, | ||
| "ticks_style": js_ticks_style, | ||
| }, | ||
| "extent": { |
There was a problem hiding this comment.
Can't you just ignore it in the other side?
There was a problem hiding this comment.
Yes, but why keep it there?
There was a problem hiding this comment.
Same as above. It will change and should. But not before the Mathics-Django release.
There was a problem hiding this comment.
Probably a good way to approach this is to start going over the API doc in mathics-threejs-backend review that and then come back here to make it match that specification.
But all of this is major API upheaval. I'd like to have at least one more stable release before that.
| if lighting == "System`Automatic": | ||
| self.lighting = [ | ||
| {"type": "Ambient", "color": [0.3, 0.2, 0.4]}, | ||
| {"type": "ambient", "color": [0.3, 0.2, 0.4]}, |
There was a problem hiding this comment.
Isn't this handled by the transformation layer in mathics-graphics3d-backend ?
There was a problem hiding this comment.
Yes, but is weird to have primitive names lower-case and light names capital-case.
There was a problem hiding this comment.
I wasn't saying this is wrong - just that mathics-threejs-backend also needs to be able to handle things like this.
The current plan is to release Mathics Django as is. And then after that settles we will have a slew of API breaking changes.
In general things, have breaking way too much recently. We need more control everywhere on limiting breakage.
There was a problem hiding this comment.
Ok, so just remove the viewpoint scaling by now as it isn't a breaking change?
There was a problem hiding this comment.
With all of the changes it is hard to follow this PR. It feels like after things settle down we should plan on a major Graphics3D in compact JSON design.
Personally, I think that all of the design work and implementation in mathics-threejs-backend could go on now if you are so disposed. Nothing prevents creating whatever API is best and converting what we have now to that.
In the PRs here in the short term we should separate breaking API from non-breaking.
Adding fields to existing JSON is fine that isn't going to break older Mathics-Django that happen use Mathics inore dev. changing existing values would. And having mathics-threejs-backend ignore existing fields is fine too.
2 participants
