You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
Upload collada file roadcurve_del.dae, autoLODs, ignore physics. Rez, select and edit the uploaded mesh. Observe the location of the pivot. Select Stretch mode and observe the opaque bounding box with handles. Observe the object dimensions. Repeat with roadcurve_del_x.dae.
Actual Behavior
With roadcurve_del.dae, (1) the pivot is not in the center of the geometry. (b) the stretch bounding box extends outside the geometry in the +x direction. (c) the x dimension is larger than that of the actual geometry. None of these happen with roadcurve_del_x.dae.
Expected Behavior
The mesh uploaded from roadcurve_del.dae should behave identically with that from roadcurve_del_x.dae.
Other information
The only difference bewtween these two files is the replacement of the x coordinate of the first entry in the vertex position list with a zero in roadcurve_del_x. This first point is not referenced in a .
The reason this leads to the effects described appears to be that the first vertex position is used in LLModel::EModelStatus load_face_from_dom_polylist [412-413] to initialize the minimum and maximum extents of the geometry. If any coordinate of that position lies outside the range of those actually referenced in a , then that value will never be replaced as the referenced positions are gathered and compared [line 548, update_min_max call]. That will leave the extent outside the range of the referenced values. Presumably the fix is to use the first position referenced in a , instead of the first in the position list, to initialise the extents. The functions load_face_from_dom_triangles and load_face_from_dom_polygons contain equivalent code that would also have to be changed in the same way.
Unreferenced vertex positions can extend bounding box and move pivot of mesh.
Type
Bug
Priority
Unset
Status
Accepted
Resolution
Accepted
Reporter
Drongle McMahon (drongle.mcmahon)
Created at
2015-04-09T05:13:10Z
Updated at
2016-12-06T11:15:54Z
{
'Business Unit': ['Platform'],
'Date of First Response': '2015-04-10T02:25:02.030-0500',
"Is there anything you'd like to add?": 'The only difference bewtween these two files is the replacement of the x coordinate of the first entry in the vertex position list with a zero in roadcurve_del_x. This first point is nor referenced in either <polylist>.\r\n\r\nThe reason this leads to the effects described appears to be that the first vertex position is used in LLModel::EModelStatus load_face_from_dom_polylist [412-413] to initialize the minimum and maximum extents of the geometry. If any coordinate of that position lies outside the range of those actually referenced in a <polylist>, then that value will never be replaced as the referenced positions are gathered and compared [line 548, update_min_max call]. That will leave the extent outside the range of the referenced values. Presumably the fix is to use the first position referenced in a <polylist>, instead of the first in the position list, to initialise the extents.\r\n\r\nThis was discovered in the course of dealing with a user problem (https://community.secondlife.com/t5/Mesh/Visible-seam-when-connecting-two-smooth-shaded-pieces/td-p/2921479)',
'Severity': 'Unset',
'System': 'SL Viewer',
'Target Viewer Version': 'viewer-development',
'What just happened?': 'With roadcurve_del.dae, (1) the pivot is nor in the center of the geometry. (b) the stretch bounding box extends outside the geometry in the +x direction. (c) the x dimension is larger than that of the actual geometry. None of these happen with roadcurve_del_x.dae.',
'What were you doing when it happened?': 'Upload collada file roadcurve_del.dae, autoLODs, ignore physics. Rez, select and edit the uploaded mesh. Observe the location of the pivot. Select Stretch mode and observe the opaque bounding box with handles. Observe the object dimensions. Repeat with roadcurve_del_x.dae.',
'What were you expecting to happen instead?': 'The mesh uploaded from roadcurve_del.dae should behave identically with that from roadcurve_del_x.dae.',
'Where': 'See environment. Also on beta grid.',
}
The text was updated successfully, but these errors were encountered:
Drongle McMahon commented at 2015-04-09T12:38:28Z, updated at 2015-04-09T16:52:53Z
Note that it is possible, although I think unlikely, that this effect has been exploited by others to deliberately offset a pivot, for example for door hinges. It's unlikely because it requires either control of exported vertex order from within authoring softare or careful editing of dae files. In any case, objects already imported would not be affected by a fix, the technique is not officially supported for new content, and alternatives, using invisible triangles, are available and well known. So I would not expect this to stand in the way of a fix. I have added the files, tstx.dae, a cube with an unconnected vertex at the end of the position list, and the edited version tstxx.dae, in which the unconnected vertex has been moved to the head of the list, to illustrate how the technique might have been used. The pivot in tstxx.dae is offset to an edge in x and y dimensions.
It would be nice to have an official supported means of making offset bounding box mesh that doesn't require more than 8 faces used or offset faces, no matter the size as they still count toward physics.
Steps to Reproduce
Upload collada file roadcurve_del.dae, autoLODs, ignore physics. Rez, select and edit the uploaded mesh. Observe the location of the pivot. Select Stretch mode and observe the opaque bounding box with handles. Observe the object dimensions. Repeat with roadcurve_del_x.dae.
Actual Behavior
With roadcurve_del.dae, (1) the pivot is not in the center of the geometry. (b) the stretch bounding box extends outside the geometry in the +x direction. (c) the x dimension is larger than that of the actual geometry. None of these happen with roadcurve_del_x.dae.
Expected Behavior
The mesh uploaded from roadcurve_del.dae should behave identically with that from roadcurve_del_x.dae.
Other information
The only difference bewtween these two files is the replacement of the x coordinate of the first entry in the vertex position list with a zero in roadcurve_del_x. This first point is not referenced in a .
The reason this leads to the effects described appears to be that the first vertex position is used in LLModel::EModelStatus load_face_from_dom_polylist [412-413] to initialize the minimum and maximum extents of the geometry. If any coordinate of that position lies outside the range of those actually referenced in a , then that value will never be replaced as the referenced positions are gathered and compared [line 548, update_min_max call]. That will leave the extent outside the range of the referenced values. Presumably the fix is to use the first position referenced in a , instead of the first in the position list, to initialise the extents. The functions load_face_from_dom_triangles and load_face_from_dom_polygons contain equivalent code that would also have to be changed in the same way.
This was discovered in the course of dealing with a user problem (https://community.secondlife.com/t5/Mesh/Visible-seam-when-connecting-two-smooth-shaded-pieces/td-p/2921479)
Note: line numbers from llmodel.cpp, current release source (I think).
Attachments
Links
Related
Original Jira Fields
The text was updated successfully, but these errors were encountered: