-
Notifications
You must be signed in to change notification settings - Fork 34
Improved Story viewport brackets and helpers #313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
1. depends on the model's scale. Fixed in #fb9a2e02 2. Coloring the transform inputs might be a very good idea, I'll try it in the future. I made them because figuring out where we are in the pose task can be really difficult when an object is far off-center or has a weird shape. We already discussed this regarding the 3. the helper's length is tied to the light's shadow near/far distances in an attempt to help users diagnose "why isn't my light casting proper shadows", which is a question I get a lot. Maybe that's not a good approach? I don't know what would be the proper size though. |
Hi, I think everything was OK except maybe the directional light helper's size. Do you want me to scale it up? Let me know if there is still issues on your side. |
Thanks for the nudge. I believe there were some usability questions as well but I will revisit and update here. |
Hi @sdumetz, I think there are still some issues to resolve.
|
Scene scaling (via an item unit change in the Pose task) also seems to cause issues with the light widget vector lines. |
@sdumetz Had a chance to dig into the issues above a little today. Proof of concept for some fixes found at https://github.com/Smithsonian/dpo-voyager/tree/Holusion-origin_helpers_debug - not suggestions for merge - some are pretty hacky, just demonstrating the issues.
Also noting that the directional light auto-scaling in CVScene was meant to address the "why aren't my lights casting the correct shadow" issues without user expertise/intervention. It would be great to revisit the issues you've seen here as, at least on our end, I'm not sure most of our users would understand the concept well enough to fix.
Didn't get a chance to look at 4 or 5, but they shouldn't be too serious. |
[WIP] implement separate Origin helper to show transform position. Make brackets children of their objects (needs cleanup and verification) begin implementation of scene axes helper remove Origin helper, merge into Bracket
update all light helpers
Co-authored-by: Jamie Cope <jamie@gcope.com>
Co-authored-by: Jamie Cope <jamie@gcope.com>
Branch updated to latest release.
I kept the color-coding minimal for now with just the labels, not sure if coloring the whole input would be better. I'll ask around for opinions. Thanks for the feedback and the fixes! |
def5eec should fix z-fighting by delegating the axes drawing to the CVGrid and @ff/three/Grid components. The normal Axes helper can still flicker a bit with the grid if it is outside it's object's occlusion, but I don't think it would matter too much. |
…andle scene units change for directional lights
Going to the far plane wasn't any good because it's generally too far away to be meaningful ( I think I nailed the origin thing. I was very confused by the maths in CVScene.updateLights but now I have something that always points from the source to the scene's origin point even when changing scene units. Of course if you edit the light's transform it stops pointing at the origin. An elevation / azimuth control for directional lights would be easier to control but that'd be another matter. I also had to add a scale factor when changing the scene units. Also took the opportunity to test with Spotlight helpers which now scale OK when switching scene units. I'm still seeing some inconsistencies when changing scene units due to how some values are internally scaled (model.position) vs transform-scaled (DirectionalLights) and I don't know which one I should apply to other lights. Due to this, Axes helpers for lights are not properly scaled when changing the scene's units. |
Looks good. Nice work!
Of course, that makes sense. Improved light controls have been on our list for some time.
Do you have a specific example I can test? I may be able to provide some clarity. I played around with it and did not see any scaling issues. |
That's because it doesn't happen on DirectionalLights. They get their transforms rescaled on unit change, which changes their axes' scale. Models don't have this issue because their axes are sized from their bounding box so they are always OK. So Axes for those lights are always "1 scene-unit" for now. I could force scale to affect the light's distance by internally multiplying them. That should probably not be considered blocking though because there is no practical way to create those light types anyway. I can always come back to it later. |
Yes, of course. It would still be useful to have a functional example of you're talking about. Maybe I'm interpreting it wrong, but if a spot light is scaled, it's effective distance should change accordingly.
That's fine with me if you don't mind opening an issue so it doesn't get lost as a todo. Thanks for all the work! |
Merged to RC-52 Nothing actionable here at the moment, but did want to note that this functionality adds some size to the Explorer build, even though the functionality isn't used there. I don't see a way it's easily avoidable at this stage due to the core integration of CSelection, but my goal is always to try and keep as much bloat out of Explorer as possible. Again, nothing actionable now but just something to keep in mind. Thanks! |
My initial goal was to provide a visual indicator for an object's current pivot point when brackets are shown.
While I was at it I improved the style of the various light helpers. to have a more distinctive look. It should make it easier to visually identify a light type and know how it will affect the scene by looking at its viewport helper.
I ended up rewriting the brackets/helpers rendering code because I couldn't get rid of some positioning and synchronization inconsistencies otherwise. I like the new system though, it saves a render pass. I did not test whether it improved performance but it shouldn't hurt.
I took the opportunity to narrow down some property constraints where possible (mainly
min: 0
where negative values wouldn't make sense).All light types should now be usable and easy-enough to configure with the visual helpers, they just lack some UI elements to add/remove lights from a scene, for which I will have a PR coming real soon.