Entity update improvements 2#830
Conversation
|
The following links are available: |
|
The following links are available:
build (macOS-latest, full) build (windows-latest, full) |
|
Initial testing ... Clear cache (Developer > Network > Clear Disk Cache). Two green cubes glTF model displayed initially, with expected collision hulls. Restart Interface, and the correct collision hull is displayed for the FBX model. Delete the models and restart Interface.' Note: Problem seems not to occur when updating the model using the Create app. |
56673f0 to
f413ad3
Compare
|
The following links are available:
build (macOS-latest, full) build (windows-latest, full) |
|
The following links are available:
build (windows-latest, full) build (macOS-latest, full) |
|
The following links are available:
build (macOS-latest, full) build (windows-latest, full) |
Co-authored-by: David Rowe <[email protected]>
|
@SilverfishVR thanks for catching that! I think it should be fixed now |
|
The following links are available: build (ubuntu-18.04, full)
build (windows-latest, full) build (ubuntu-18.04, android) |
|
PR830-705a90f:
|
|
Need to test both connecting to a domain and reloading content, in current 2020.3.2 release and this PR. |
|
The following links are available: build (ubuntu-18.04, full)
build (windows-latest, full) build (ubuntu-18.04, android) |
|
did a fresh install with PR830-5e5e507 to test the collision hull loading issue:
|
|
so, there is definitely some differences in how model scale is handled with this pr:
so, model size is correct but bounding box and collision is off. And if you rescale the rectangle in create, and switch to the sphere, it will be squished because the aspect ratio is off.
So, I think there is no "solve it all" solution to this, since only size(x,y,z) is stored, but not scale(x,y,z), wearables used to apply some form of arbitrary scale and that f'ed up all the time so I would not want to apply that kind of complex logic to models in general. The behaviour of this PR of keeping collision and bounding box in line with the displayed model is prefered, but maybe the scale should be reset when changing the model url? it will also be very annoying when iterating through models that are not to scale, having to rescale every time 🤔 pick your poison I guess 😃 |
|
@SilverfishVR that scaling behavior is intentional, and I think it’s in line with what was originally intended by the code. the problem is that if someone manually modified the dimensions to something other than the natural dimensions, then I’d expect them to want those dimensions to carry over when the URL changes. but I agree it might not always be what they want otherwise. but I think this way is most flexible. people can always set the dimensions to the new naturalDimensions, but if we did the other behavior, there would be no way to “go back” to the OLD dimensions. regarding reloading content, it sounds like the problem is that we need safe landing to start again, but since safe landing doesn’t work perfectly, that might not be ideal. reloading content is supposed to be more of a development tool so I think this is ok for now |
digisomni
left a comment
There was a problem hiding this comment.
With some cursory testing over all the test cases, everything appears to be working as expected. :)
|
The following links are available: build (ubuntu-18.04, full)
build (windows-latest, full) |
also fixes #681
The current rendering code is a mess of locks and threads and chaos. This is an attempt to disentangle some things, hopefully resulting in some performance improvements.
The general idea is:
emit requestRenderUpdate()and needsRenderUpdate can be removedTest plan:
oto toggle the modelURL. Verify that the dimensions and the collision shape are correct.