<HTML><HEAD>
<META content="MSHTML 6.00.6000.16939" name=GENERATOR>
<STYLE>P {
MARGIN: 5px 0px
}
</STYLE>
<META content=LVOLVSQYUN name=SKYPE_FRAMEID></HEAD>
<BODY style="FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 250">
<P>Dear Joe,</P>
<P> </P>
<P>>> > 3. Physical units specification <BR>><BR>>Please let me use a minute to describe Joe's view on the Units <BR>>question and 3.3 solution. <BR>><BR>>To me, now, there is only one user-orented reason for this update to <BR>>add an optional Units respecifier. <BR>><BR>>The author wishes to enter coordinate values in the units of interest. <BR>>That is, if working in cm then instead of encoding the value as: <BR>>0.1 0.1 0.1 <BR>>it would be written as: <BR>>1 1 1 <BR>>In this case the author would also include the Units statement, <BR>>declaring <BR>>cm 0.1 <BR>>to alert the browser that the file is to be interpreted as if the <BR>>numeric values relating to length are included in cm rather than m. <BR>><BR>>This provides a solution in the many situations where it is more <BR>>accurate and convenient to maintain data in certain numeric units of <BR>>resolution different than the X3D defaults. </P>
<P> </P>
<P>Yes. Definitely. <BR>This description means we can avoid the invisiblity of objects due to using the conversion factor. <BR>I prefer not using "conversion factor" but using just "cm" because the conversion factor defined means that browsers must apply the conversion factor to the coordinates when they encounter it in an X3D file. </P>
<P> </P>
<P>>When the browser reads this file, it would render the geometry as if <BR>>the scene was contained by scale 0.1 0.1 0.1 and render it as expected <BR>>in relation to other geometry in the scene. <BR>></P>
<P> </P>
<P>This means that the conversion factor is applied to the file, and then performs scaling 0.1, i.e., 1 1 1 coordinates are converted 0.1 0.1 0.1. Then, objects in the scene become smaller by 0.1. Is this right?<BR>It follows, then, that if the conversion factor is 0.0001, we cannot see the objects in the scene because of the resolution problem. </P>
<P> </P>
<P>>Important to note that this is sort of a phantom scaling because files <BR>>included by Inlines are not affected by their parent file Units <BR>>declaration, but only by any declaration in each individual file. </P>
<P> </P>
<P>I suppose that inlines and importing several x3d files are the same functions in a scene.<BR>Then, your consideration is that the inlined files are not affected by parent files.<BR>This means that the parent's unit is km, the parent's coordinates 1 1 1;<BR>the inline's unit is mm, and the inline's coordinates 1 1 1 too;<BR>then they look the same in their size, although the units' difference is 1000,000. Is this ok? <BR>Then, it seems that the conversion factor has no meaning based on the following points:</P>
<P>(1) because there are a lot of cases in which we cannot see the objects when applying<BR> scaling factors because of the resolution problem mentioned above.<BR> <BR>(2) there is no resolution problem when we interpret 1 1 1 coordinates with cm unit<BR> as the coordinates themselves are cm based. </P>
<P>Regarding the implementation of inlines' units, ignoring it may be one choice to avoid misinterpretation depending on applications. </P>
<P> </P>
<P>>The author's intent and the functionality is maintained. Consistent <BR>>use of Units declarations, even if defaut units are used, will solve <BR>>many longstanding authoring problems encountered when combining scenes <BR>>from several sources. <BR>><BR>>Treating each file completely independently according to its Units <BR>>specifier allows this to work without producing a cascading <BR>>inheritance effect. <BR>><BR>>So, the key elements are: <BR>><BR>>1 Units statement per file. <BR>>Parent file Units does not affect sibling files. <BR>>Browser rescales file contents for rendering according to declared <BR>>Units. </P>
<P> </P>
<P>Does this mean that the inlined files are rescaled according to the parent units?<BR>Then, does this mean the inlined files are affected by the parent units,<BR>because the inlined files would be transformed according to the parent units?</P>
<P>If not, please ignore these.</P>
<P>. <BR>>It may be important at some point in time for the author to become <BR>>aware that regardless of the convenience, there is a real world out <BR>>there and that regardless of the need, when the standard browser is <BR>>working, the SAI data will be probably be scaled in default units of <BR>>the scenegraph for rendering. Without allowance for the equipment <BR>>resolution, errors similar to rounding may occur. A problem is keeping <BR>>the units in terms of the author's intent when serializing the final <BR>>combined scene. When simulating at the extremes, we may need to make <BR>>special arrangements with our browser core programmer. </P>
<P> </P>
<P>I understand that combining scenes with very different units such as km and micrometer<BR>should also be possible in a scene. For example, in a classroom, we must see <BR>the real classroom's size and also microbiology in the virtual projector in the scene.<BR>In this case, we need not rescale the microbiology.</P>
<P>Then, what do you think of the following implementation?</P>
<P>1) in the case that relative scaling is necessary, for example, when importing two CAD objects with the same units, automatic rescaling is used according to the parent's units.</P>
<P>2) in the case that relative scaling is not necessary, for example, a real classroom and a microbiology on the virtual projector, rescaling is not done, and two separate scenes are combined into a scene without relative scaling. <BR> <BR>In order to classify the above, it seems that a flag such as "rescaling" is needed so that<BR>applications can choose an option. The default is no rescaling. </P>
<P><BR>>"7.2.5.5 UNIT statement <BR>>... <BR>>"UNIT statements contained in X3D files referenced by Inline nodes or <BR>>contained in X3D files consisting of EXTERNPROTO bodies shall be used <BR>>to convert effected units to the base units of the root file before <BR>>the referenced X3D file content is incorporated in the X3D world." <BR>><BR>>So, I read this to say that if the root (parent) world is in cm and <BR>>the Inline file is in cm, there would be no conversion. <BR>><BR>>I hope this helps. <BR>>Thank You and Best Regards, <BR>>Joe </P>
<P>Thank you very much.</P>
<P> </P>
<P>Sincerely,<BR><BR>Myeong Won Lee<BR></P>
<DIV> </DIV>
<BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN: 0px; BORDER-LEFT: black 2px solid">
<DIV style="COLOR: black; LINE-HEIGHT: 140%">---- Original Message ----<BR></DIV>
<DIV style="COLOR: black"><B>From : </B>Joe D Williams(joedwil@earthlink.net)<BR></DIV>
<DIV style="COLOR: black; LINE-HEIGHT: 140%"><B>To : </B>\Myeong Won Lee\(mwlee@suwon.ac.kr); korea-chapter@web3d.org<BR></DIV>
<DIV style="COLOR: black; LINE-HEIGHT: 140%"><B>Cc : </B>x3d@web3d.org<BR></DIV>
<DIV style="COLOR: black; LINE-HEIGHT: 140%"><B>Sent : </B>Thursday, Nov 12, 2009 10:11 AM<BR></DIV>
<DIV style="COLOR: black; LINE-HEIGHT: 140%"><B>Subject : </B>Re: [X3D] Agenda items for the Korea chapter meeting (Wed. 5:10pm PST / Thu 10:10am Korea)<BR></DIV><BR>> > 3. Physical units specification <BR><BR><BR><BR>Please let me use a minute to describe Joe's view on the Units <BR><BR>question and 3.3 solution. <BR><BR><BR><BR>To me, now, there is only one user-orented reason for this update to <BR><BR>add an optional Units respecifier. <BR><BR><BR><BR>The author wishes to enter coordinate values in the units of interest. <BR><BR>That is, if working in cm then instead of encoding the value as: <BR><BR>0.1 0.1 0.1 <BR><BR>it would be written as: <BR><BR>1 1 1 <BR><BR>In this case the author would also include the Units statement, <BR><BR>declaring <BR><BR>cm 0.1 <BR><BR>to alert the browser that the file is to be interpreted as if the <BR><BR>numeric values relating to length are included in cm rather than m. <BR><BR><BR><BR>This provides a solution in the many situations where it is more <BR><BR>accurate and convenient to maintain data in certain numeric units of <BR><BR>resolution different than the X3D defaults. <BR><BR><BR><BR>When the browser reads this file, it would render the geometry as if <BR><BR>the scene was contained by scale 0.1 0.1 0.1 and render it as expected <BR><BR>in relation to other geometry in the scene. <BR><BR><BR><BR>Important to note that this is sort of a phantom scaling because files <BR><BR>included by Inlines are not affected by their parent file Units <BR><BR>declaration, but only by any declaration in each individual file. <BR><BR><BR><BR>The author's intent and the functionality is maintained. Consistent <BR><BR>use of Units declarations, even if defaut units are used, will solve <BR><BR>many longstanding authoring problems encountered when combining scenes <BR><BR>from several sources. <BR><BR><BR><BR>Treating each file completely independently according to its Units <BR><BR>specifier allows this to work without producing a cascading <BR><BR>inheritance effect. <BR><BR><BR><BR>So, the key elements are: <BR><BR><BR><BR>1 Units statement per file. <BR><BR>Parent file Units does not affect sibling files. <BR><BR>Browser rescales file contents for rendering according to declared <BR><BR>Units. <BR><BR>. <BR><BR>It may be important at some point in time for the author to become <BR><BR>aware that regardless of the convenience, there is a real world out <BR><BR>there and that regardless of the need, when the standard browser is <BR><BR>working, the SAI data will be probably be scaled in default units of <BR><BR>the scenegraph for rendering. Without allowance for the equipment <BR><BR>resolution, errors similar to rounding may occur. A problem is keeping <BR><BR>the units in terms of the author's intent when serializing the final <BR><BR>combined scene. When simulating at the extremes, we may need to make <BR><BR>special arrangements with our browser core programmer. <BR><BR><BR><BR>"7.2.5.5 UNIT statement <BR><BR>... <BR><BR>"UNIT statements contained in X3D files referenced by Inline nodes or <BR><BR>contained in X3D files consisting of EXTERNPROTO bodies shall be used <BR><BR>to convert effected units to the base units of the root file before <BR><BR>the referenced X3D file content is incorporated in the X3D world." <BR><BR><BR><BR>So, I read this to say that if the root (parent) world is in cm and <BR><BR>the Inline file is in cm, there would be no conversion. <BR><BR><BR><BR>I hope this helps. <BR><BR>Thank You and Best Regards, <BR><BR>Joe <BR><BR><BR><BR><BR><BR><BR><BR>----- Original Message ----- <BR><BR>From: ""Myeong Won Lee"" <mwlee@suwon.ac.kr> <BR><BR>To: <korea-chapter@web3d.org> <BR><BR>Cc: <x3d@web3d.org> <BR><BR>Sent: Tuesday, November 10, 2009 11:03 PM <BR><BR>Subject: [X3D] Agenda items for the Korea chapter meeting (Wed. 5:10pm <BR><BR>PST / Thu 10:10am Korea) <BR><BR><BR><BR><BR><BR>> The following are the agenda items for this week's Korea chapter <BR><BR>> meeting, November 11 (Wed) 5:10pm (PST)/November 12 (Thu) 10:10am <BR><BR>> (Korea). Please provide updates if any amendments or additions are <BR><BR>> noted. <BR><BR>> <BR><BR>> 1. Projective Texture Mapping (Kwan Hee Yoo, Chungbuk National U.) <BR><BR>>>First, it is very important that these documents get posted to the <BR><BR>>>website. <BR><BR>>> <BR><BR>> ... <BR><BR>>>2 questions: do your three proposed texture nodes work similarly to <BR><BR>>>the <BR><BR>>>other X3D texture nodes with scope restricted to the geometry in the <BR><BR>>>same Shape node. For example: <BR><BR>>> <BR><BR>>>Shape <BR><BR>>>Geometry node <BR><BR>>>Appearance <BR><BR>>>Material <BR><BR>>>Texture node <BR><BR>>> <BR><BR>>>Hopefully the functionality DEF and USE are the same, for example <BR><BR>>>the same OrthoTexture might have a single DEF and 2 USE instances <BR><BR>>>to apply to the geometry found in 3 different Shape nodes. <BR><BR>>> <BR><BR>>>(I think the answers are yes, but will let Kwanhee Yoo answer by <BR><BR>>>email.) <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> Kwan Hee will address updates. <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> 2. Mixed reality functions (Gun Lee, ETRI) <BR><BR>> <BR><BR>>>> Gun has also defined the mixed reality functions as new nodes. <BR><BR>>>> It is necessary to review this and decide if these node <BR><BR>>>> definitions are <BR><BR>>>> appropriate for including the new functions in X3D. <BR><BR>>> <BR><BR>>>Unfortunately Gun has not yet received comments about these nodes. <BR><BR>>>He would like to begin implementing them, likely using CyberX3D for <BR><BR>>>C++. <BR><BR>>>http://www.cybergarage.org/vrml/cx3d/cx3dcc/index.html <BR><BR>>>He will contact the owner, Satoshi Konno in Tokyo. <BR><BR>>> <BR><BR>>>Johannes and Yvonne, Fraunhofer has some similar nodes. Have you <BR><BR>>>you looked at this? Should there be a conference to discuss the <BR><BR>>>nodes before he implements? Please advise what you think. <BR><BR>>> <BR><BR>>>Feedback from other browser implementers is welcome also. Please <BR><BR>>>advise. <BR><BR>> <BR><BR>> <BR><BR>> Gun will address updates. <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> 3. Physical units specification (Myeong Won Lee, The University of <BR><BR>> Suwon) <BR><BR>> <BR><BR>> The unit browser is being modified from the previous Physical node <BR><BR>> definition to the UNIT statements. There were contradictions in the <BR><BR>> email discussion of the X3D WG. We must decide amongst the following <BR><BR>> when determining which criteria should be applied in the <BR><BR>> implementation of the length units: <BR><BR>> <BR><BR>> <BR><BR>> (1) Length units are defined but do not affect the visual scene at <BR><BR>> all where there is no scaling. They transfer length units <BR><BR>> information only. In this case, we cannot compare differences in <BR><BR>> real length when two X3D objects designed separately are read into a <BR><BR>> scene using an inline node or by reading two X3D files together in a <BR><BR>> scene. There is no difference at all in the scene compared with no <BR><BR>> unit definition. <BR><BR>> <BR><BR>> <BR><BR>> (2) Length units are defined and do not scale objects when reading <BR><BR>> an X3D file, but relative scales are used when reading two <BR><BR>> units-specified X3D files together in a scene using inline nodes or <BR><BR>> by importing another unit X3D file. We must not scale objects when <BR><BR>> reading an X3D file because we cannot see the scaled objects of very <BR><BR>> large and small objects such as those of astronomical and <BR><BR>> microorganism size. It is desirable to use the same units in X3D <BR><BR>> files when it is necessary to have relative scales. <BR><BR>> <BR><BR>> I prefer the latter case (2). <BR><BR>> <BR><BR>> 5. H-Anim motion data definition (Myeong Won Lee, The University of <BR><BR>> Suwon) <BR><BR>> <BR><BR>> We define a Motion Capture node for H-Anim figures in order to <BR><BR>> transfer the data of moving H-Anim figures. It provides an interface <BR><BR>> between H-Anim data and motion capture data. An H-Anim viewer has <BR><BR>> been developed and continues to be updated. A summarized <BR><BR>> presentation file will be sent to X3D and H-Anim WGs soon. <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> 6. Mobile X3D functions (Myeong Won Lee, The University of Suwon) <BR><BR>> <BR><BR>> A mobile X3D viewer is being developed according to the X3D <BR><BR>> interactive profile. As presented at the SC24 London meeting, the <BR><BR>> progressive mesh function is necessary for the server side program, <BR><BR>> but it seems unnecessary for the client side viewer. However, the <BR><BR>> GPS function is necessary to include in mobile X3D. Therefore, we <BR><BR>> propose a GPS node for mobile X3D. <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> 7. Web3D Korea Workshop, November 28, Seoul, Korea <BR><BR>> <BR><BR>> We will have a Web 3D Standardization Workshop at Ewha Womans <BR><BR>> University, which is the venue of the conference held twice annually <BR><BR>> by the Korean Institute of Information Scientists and Engineers. <BR><BR>> Thirteen standardization items will be presented in the areas of <BR><BR>> X3D, CAD, education, medicine, GIS, Image, mobile, etc. <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> 8. Web3D Korea Chapter Seoul meeting, December 7-8, 2009, Seoul, <BR><BR>> Korea <BR><BR>> I will prepare the program and and inform everyone. <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> 9. Our next Korea chapter meeting is planned for: <BR><BR>> <BR><BR>> November 25 (Wed) 5:10pm (PST) / November 26 (Thu) 10:10am (Korea), <BR><BR>> OR <BR><BR>> December 2 (Wed) 5:10pm (PST) / December 3 (Thu) 10:10am (Korea) <BR><BR>> <BR><BR>> <BR><BR>> <BR><BR>> Sincerely, <BR><BR>> <BR><BR>> -- <BR><BR>> Myeong Won Lee <BR><BR>> Dept. of Internet Information Engineering, U. of Suwon <BR><BR>> Hwasung-si, Gyeonggi-do, 445-743 Korea <BR><BR>> Tel) +82-31-220-2313, +82-11-9904-4634 <BR><BR>> E-mail) mwlee@suwon.ac.kr <BR><BR>> <BR><BR>> <BR><BR><BR><BR><BR><BR>-------------------------------------------------------------------------------- <BR><BR><BR><BR><BR><BR>> _______________________________________________ <BR><BR>> X3d mailing list <BR><BR>> X3d@web3d.org <BR><BR>> http://web3d.org/mailman/listinfo/x3d_web3d.org <BR><BR>></BLOCKQUOTE>
<!-- Mail Slogan Start -->
<!-- Mail Slogan End -->
</BODY></HTML><img width=0 height=0 src="http://mail.suwon.ac.kr/mail/rcptcheck.html/eVWZqUzNjY0/VRQStk1NzI2N/5c_jsrW3ObKwlrE0sDg6sjkgu7IxmTIXtzmz/foo.gif">