[x3d-public] Extrusions, take 3: initial proposed spec changes

Don Brutzman brutzman at nps.edu
Fri Feb 5 21:39:41 PST 2016


sorry for gapped repsonses, am proceeding at best speed amidst many tasks.

not sure if the Harrier is OK... student-produced content is pretty snaky sometimes.  they often find very unpredictable test cases. will try working with it again at some point.

other test cases are probably better.  we have a number.  hard to keep track without a dedicated sharable wiki page on this.

btw the porse i posted was the result of Roy, Dick, Leonard and I working together for an hour and a half on a weekly telcon. everything was edited and inspected in mantis.  time consuming business.

We will work on this again, and again, and again until every case is resolved.  You are most welcome to join us each time.

Most every other codebase works on most cases.  I offered the relevant code excerpts from X3D

Too bad the wiki doesn't seem to work, I think that has really slowed us all down.

Thanks for keeping the topic alive Seva, very important.


On 2/3/2016 7:08 PM, Alekseyev, Vsevolod (NIH/NIAID) [E] wrote:
>>The old content would still be there, you would just be able to say with authority that the content was invalid or incorrect.
>
> That's exactly what I'm after. Right now, X3DOM misrenders the Harrier plane (the wings are backwards), and I can't even file a bug, because there's no legitimate answer as to what's incorrect here - the scene or X3DOM. I find that situation rather unsatisfactory, contrary to the way software specs are supposed to work.
>
>> If so, is there anything that the WG should include in the definition that would solve this problem or (at least) make your job easier?
>
> Don has already addressed some of my concerns on 1/27.
>
> On #1 (-Y spine), he was no help, I'm afraid. Of course the SCP would be perpendicular to the spine, but what are the axes? There's a whole [0..2Pi) worth of freedom there.
>
> On #2 (coincident points in the middle), he amended the angle rule to use previous/next *distinct* spine point(s) for SCP vector calculation instead of physically previous/next ones. This is what I thought all along was the best resolution of the conundrum, but that's not what I have in code, since it would contradict the existing wording of the standard.
>
> On #3 (collinear, but not straight spine) I'm frankly not sure what did he mean.
>
> When I wrote my tl;dr question, I expected the answer to be in form of vectors. Or a drawing. Since the WG won't provide reference code as a matter of principle (we've discussed that the other day), a reference *result* would be the next best thing. I think it would help both me and the WG's clarity of thought if someone from the WG would take some time to make the calculations by hand and produce the numeric answer to my question. Draw the spine, apply the rules, etc.
>
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> *From:* Leonard Daly [Leonard.Daly at realism.com]
> *Sent:* Wednesday, February 03, 2016 9:17 PM
> *To:* Alekseyev, Vsevolod (NIH/NIAID) [E]; x3d-public at web3d.org
> *Subject:* Re: [x3d-public] Extrusions, take 3: initial proposed spec changes
>
> Seva,
>
>
>> I'm *importing* X3Ds into Blender, not exporting them. Extrusion is a part of the X3D standard. Whether a scene was written by hand or generated by a tool, Blender shouldn't choke on it, or produce meshes that are inconsistent with other X3D implementations. Right now it does both, because the standard is incomplete.
>
>
> I'm sorry I misunderstood. I thought you were trying to create X3D content that contained an extrusion object. Suppose there was a complete standard for Extrusion, and suppose it agreed exactly with what Blender does. Would that really change anything? The old content would still be there, you would just be able to say with authority that the content was invalid or incorrect. Would you still be required to deal with the old incorrect/invalid content? If so, is there anything that the WG should include in the definition that would solve this problem or (at least) make your job easier?
>
>
> Leonard Daly
>
>
>
>
>>
>>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 ---
>> *From:* Leonard Daly [Leonard.Daly at realism.com]
>> *Sent:* Wednesday, February 03, 2016 5:38 PM
>> *To:* Alekseyev, Vsevolod (NIH/NIAID) [E]; x3d-public at web3d.org
>> *Subject:* Re: [x3d-public] Extrusions, take 3: initial proposed spec changes
>>
>> Seva,
>>
>> Clarifying the details for V3.x is good and important for historical purposes.
>>
>> What code produces Extrusion nodes? I checked the Blender file out (for .blend at http://archive.blender.org/development/architecture/blender-file-format/ and http://www.atmind.nl/blender/blender-sdna.html) and did not find any reference to an extrusion node. I don't think the X3D exporter does either.
>>
>> If you have a very limited set of extrusion generators, it would be helpful to know. There are edge cases in all simple extrusions and it may be possible to write the specification to match they way those applications generated it.
>>
>>
>> Leonard Daly
>>
>>
>>> I am putting together an X3D importer for Blender, and, potentially, for another open source project. As a part of that effort, I have to convert X3D geometries, all 15 of them, into vertex/face arrays. As long as there are X3D 3.3 scenes out there, Extrusion support is not going away.
>>>
>>> I’m not **using** extrusions in any meaningful sense. All I want is a standard that covers the entire parameter space. Is that too much to ask for?
>>>
>>> *From:*Leonard Daly [mailto:Leonard.Daly at realism.com]
>>> *Sent:* Wednesday, February 03, 2016 11:04 AM
>>> *To:* x3d-public at web3d.org
>>> *Subject:* Re: [x3d-public] Extrusions, take 3: initial proposed spec changes
>>>
>>> Seva,
>>>
>>> What do you use Extrusion for?
>>>
>>> I am thinking that the node may not be needed anymore. There are a couple of use cases that I haven't figured out yet and I wish to make sure your uses are understood and a functional solution exists in V4.
>>>
>>>
>>> Leonard Daly
>>>
>>>
>>>
>>>
>>> On 2/3/2016 5:36 AM, Alekseyev, Vsevolod (NIH/NIAID) [E] wrote:
>>>
>>>         "If only 2 non-coincident spine points are provided, the corresponding SCP planes for each are perpendicular to the vector defined by these two points."
>>>
>>>
>>>
>>>     That doesn't help clarify the issue at all. First, this language adds nothing to the "coincident spine -> rotate the XZ" rule, second, axes in the plane must be defined, not just the plane itself. And, as we all can see from the misplaced wings onhttp://www.jishop.com/temp/x3d/#AV8bHarrier  , the choice of axes does matter.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     ________________________________________
>>>
>>>     From: Don Brutzman [brutzman at nps.edu <mailto:brutzman at nps.edu>]
>>>
>>>     Sent: Wednesday, January 27, 2016 12:44 PM
>>>
>>>     To: Alekseyev, Vsevolod (NIH/NIAID) [E]; x3d public mailing list
>>>
>>>     Subject: Re: [x3d-public] Extrusions, take 3: initial proposed spec changes
>>>
>>>
>>>
>>>     Thanks again Seva for the excellent test cases.
>>>
>>>
>>>
>>>     Dick, Leonard, Roy and I worked on today's weekly X3D Working Group teleconference to craft improved specification prose.  Details follow.
>>>
>>>
>>>
>>>     Next week we would like to continue with the prior wiki page examples, plus the long series of emails on this and related threads.
>>>
>>>     http://www.web3d.org/wiki/index.php/Extrusion_Edge_Cases
>>>
>>>
>>>
>>>     Together we created new Mantis issue 923 from the mail, with responses as follows.  Review and comment welcome.
>>>
>>>
>>>
>>>     Access note:  Web3D members have access to all issues.
>>>
>>>
>>>
>>>     Issue 0000923: 13.3.5 Extrusion - Edge cases
>>>
>>>     http://www.web3d.org/member-only/mantis/view.php?id=923
>>>
>>>
>>>
>>>     ==========================================================================
>>>
>>>     ==========================================================================
>>>
>>>     ==========================================================================
>>>
>>>     Description:
>>>
>>>
>>>
>>>     Hi X3D community,
>>>
>>>
>>>
>>>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Extrusion  [^]
>>>
>>>
>>>
>>>     I've tried and failed twice to explain the problems with the definition of the Extrusion node. So here's a tl;dr version:
>>>
>>>
>>>
>>>     Dear authors of the X3D standard, please take a careful look at the standard and answer me:
>>>
>>>
>>>
>>>     1) When the spine goes (0,0,0)-(0,-1,0), what is the SCP?
>>>
>>>     Note: all answers but one will render one of the reference models in the Savage archive invalid.
>>>
>>>
>>>
>>>     2) When the spine goes (0,0,0)-(0,1,0)-(0,0,0), what is the SCP?
>>>
>>>
>>>
>>>     3) When the spine goes (0,0,0)-(1,1,0)-(1,1,0)-(1,1,0)-(2,0,0), what is the SCP for the three middle points?
>>>
>>>     ==========================================================================
>>>
>>>     ==========================================================================
>>>
>>>     ==========================================================================
>>>
>>>
>>>
>>>     Case (1). Need to clearly define SCP when only 2 spine points are defined.
>>>
>>>
>>>
>>>     13.3.5.3 Algorithmic description
>>>
>>>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Algorithmicdescription  [^]
>>>
>>>
>>>
>>>     Suggested prose additions:
>>>
>>>     "If only 2 non-coincident spine points are provided, the corresponding SCP planes for each are perpendicular to the vector defined by these two points."
>>>
>>>
>>>
>>>     "If fewer than 2 non-coincident spine points are provided, the extrusion is not well defined and no results are rendered."
>>>
>>>
>>>
>>>     ======================================
>>>
>>>
>>>
>>>     Case (2), first consideration. The prose for orientation is inserted in the middle of the SCP definition. This muddles the definition for SCP.
>>>
>>>
>>>
>>>     Suggested move for existing sentences:
>>>
>>>           "The SCP is then rotated by the corresponding orientation value. This rotation is performed relative to the SCP. For example, to impart twist in the cross-section, a rotation about the Y-axis (0 1 0) would be used. Other orientations are valid and rotate the cross-section out of the SCP."
>>>
>>>
>>>
>>>     Place these as a new paragraph at the end of the section, after the complete definition of SCP. With slight modification:
>>>
>>>
>>>
>>>           "Each SCP is then rotated by the corresponding orientation value. This rotation is performed relative to the SCP itself. For example, to impart twist in the cross-section, a rotation about the local Y-axis (0 1 0) would be used. Other orientation values are valid and may rotate the cross-section out of the plane of the original SCP."
>>>
>>>
>>>
>>>     ======================================
>>>
>>>
>>>
>>>     Case (2), second consideration. Does the existing algorithm handle the example in question, in that three sequential spine points are defined where the first and third are coincident? This is a kind of reflection upon itself.
>>>
>>>
>>>
>>>     We would expect to have 3 SCPs, each parallel, where the first and third are coincident. We further need to be careful with plane orientation (direction of normal) for each of these SCPs.
>>>
>>>
>>>
>>>     When 2 vectors are coincident head-to-tail (and vice versa) the cross product does not appear to be well defined, since many perpendiculars are possible. A similiar situation may occur if they two vectors are parallel. These appear to be a special case.
>>>
>>>
>>>
>>>     These circumstances appear to be addressed in the following section.
>>>
>>>     13.3.5.4 Special cases
>>>
>>>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Specialcases  [^]
>>>
>>>
>>>
>>>     ======================================
>>>
>>>
>>>
>>>     Case (3). Suggested specification prose revision.
>>>
>>>
>>>
>>>           "If two points are coincident, they both have the same SCP."
>>>
>>>
>>>
>>>     is better expressed by
>>>
>>>
>>>
>>>           "If two or more sequential points in a spine array are coincident, they are each treated as a single point when computing the corresponding SCP, and each will have an identical SCP.
>>>
>>>
>>>
>>>     NOTE. This case is useful when animating the spine array without needed to simultaneously modify the corresponding orientation and scale arrays."
>>>
>>>
>>>
>>>     ======================================
>>>
>>>     Additional change A.
>>>
>>>
>>>
>>>     Figure 13.5 title is "Spine-aligned cross-section plane at a spine point." <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#f-Spine-alignedcross-section[%5E]Needtoadd>
>>>
>>>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#f-Spine-alignedcross-section [^] <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#f-Spine-alignedcross-section[%5E]Needtoadd>
>>>
>>>     <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#f-Spine-alignedcross-section[%5E]Needtoadd>
>>>
>>>     Need to add " <http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#f-Spine-alignedcross-section[%5E]Needtoadd>(SCP)" in the figure title above.
>>>
>>>
>>>
>>>     ======================================
>>>
>>>     Additional change B.
>>>
>>>
>>>
>>>     13.3.5.4 Special cases
>>>
>>>     http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geometry3D.html#Specialcases  [^]
>>>
>>>
>>>
>>>     Change
>>>
>>>           "If two points are coincident, they both have the same SCP."
>>>
>>>
>>>
>>>     to
>>>
>>>           "If two sequential spine points are coincident, they both have the same SCP."
>>>
>>>
>>>
>>>     ==========================================================================
>>>
>>>     ==========================================================================
>>>
>>>     ==========================================================================
>>>
>>>
>>>
>>>     all the best, Don
>>>
>>>     --
>>>
>>>     Don Brutzman  Naval Postgraduate School, Code USW/Brbrutzman at nps.edu <mailto:brutzman at nps.edu>
>>>
>>>     Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
>>>
>>>     X3D graphics, virtual worlds, navy roboticshttp://faculty.nps.edu/brutzman
>>>
>>>
>>>
>>>     _______________________________________________
>>>
>>>     x3d-public mailing list
>>>
>>>     x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>>>
>>>     http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>>
>>>
>>> --
>>> *Leonard Daly*
>>> 3D Systems & Cloud Consultant
>>> X3D Co-Chair on Sabbatical
>>> LA ACM SIGGRAPH Chair
>>> President, Daly Realism - /Creating the Future/
>>>
>>
>>
>> --
>> *Leonard Daly*
>> 3D Systems & Cloud Consultant
>> X3D Co-Chair on Sabbatical
>> LA ACM SIGGRAPH Chair
>> President, Daly Realism - /Creating the Future/
>
>
> --
> *Leonard Daly*
> 3D Systems & Cloud Consultant
> X3D Co-Chair on Sabbatical
> LA ACM SIGGRAPH Chair
> President, Daly Realism - /Creating the Future/
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>


all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman



More information about the x3d-public mailing list