[Korea-chapter] [X3D] Agenda items for the Korea chapter meeting (Wed. 5:10pm PST / Thu 10:10am Korea)

[Alan Hudson]

Myeong Won Lee wrote:
> Dear Alan,
> 
>  
> 
>  >Myeong Won Lee wrote:
>  >> 3. Physical units specification (Myeong Won Lee, The University of Suwon)
>  >>
>  >> The unit browser is being modified from the previous Physical node 
> definition to
>  >> the UNIT statements.  There were contradictions in the email discussion of the
>  >> X3D WG. We must decide amongst the following when determining which criteria
>  >> should be applied in the implementation of the length units:
>  >>
>  >> (1) Length units are defined but do not affect the visual scene at all where
>  >> there is no scaling. They transfer length units information only. In this case,
>  >> we cannot compare differences in real length when two X3D objects designed
>  >> separately are read into a scene using an inline node or by reading two X3D
>  >> files together in a scene.  There is no difference at all in the scene compared
>  >> with no unit definition.
>  >>
>  >this makes no sense, whats the purpose of length units then.
> 
>  
> 
> I agree with some of your statement, but there does exist some difference. For 
> example, consider two X3D files. One is referencing a 1 cm X3D object. The other 
> is referencing a 1 meter X3D object. In the display, 1 cm and 1 m objects may 
> appear to be the same size when only one of them is displayed at a time, or if 
> they are imported into the same scene one after the other. In this case, 
> applications know their real sizes from the units-specified file although their 
> relative scaling cannot be estimated in the display.
> 
> We may, however, avoid this misinterpretation depending on a way to recognize 
> units.
> 
> In other words, this case does not have merit for browsers per se, but does have 
> merit when transferring real-sized 3D objects between applications.
> 
>  
> 
>  >> (2) Length units are defined and do not scale objects when reading an X3D file,
>  >> but relative scales are used when reading two units-specified X3D files 
> together
>  >> in a scene using inline nodes or by importing another unit X3D file. We must 
> not
>  >> scale objects when reading an X3D file because we cannot see the scaled objects
>  >> of very large and small objects such as those of astronomical and microorganism
>  >> size. It is desirable to use the same units in X3D files when it is 
> necessary to
>  >> have relative scales.
>  >>
>  >the easiest implementation of units would be a transform that changes
>  >any non meter speced files into meters with an implicit transform that
>  >the top of the file.
> 
>  
> 
> If we transform any unit into meter every time, we may get scenes with invisible 
> objects. For example, if we try to display a 1 km X3D object, the browser may 
> transform it into 1000 m one, 1000 multiplication and we cannot see the object 
> in the scene. This is inappropriate. Rather, it is better that the browser 
> displays it as the same, i.e. 1000, but knows its unit is km.
> 
>  
I'm not disagreeing that its better.  But a standard should not limit
implementors.  If they choose to use a scale to align these worlds
that's their business.  If they have a double pipeline then the scale
likely will work just fine.  Or if there browser is optimized for mostly
human level things it will work fine.  By introducing language about the
browser not using a scale you are forcing a particular implementation on
the browser implementor.  One which might be fairly hard.
> 
>  >Are you suggesting thats not a legal implementation?  A browser can do
>  >better if it detects that all files are the same units or that all files
>  >are really small(ie then everything might get transformed to millimeters).
>  >
>  > But you can't force that type of smart implementation on a browser.
>  >Just converting everything to meters must be legal.
>  >
>  >You language about "do no scale units when reading an x3d file" makes no
>  >sense to me.  Its one valid implementation.
> 
>  
> 
> Here is another example that converting everything to meters may result in 
> scenes with invisible objects. Consider that a designer created a bacteria using 
> the micrometer unit. The designer may use 1 1 1 coordinates for the bacteria. If 
> converting to meters, then we have 0.000001 0.000001 0.000001 coordinates and we 
> cannot see the bacteria in the display.
> 
and that's acceptable.  Browser can differeniate themselves on how well
they implement that capability.  By requiring a no-scale solution you
force a fairly complicated implementation.  This makes it harder to be
x3d conformant.

> Therefore, I would like to suggest "do not scale units when reading an x3d file 
> in a scene".  However, relative scaling is convenient if two or more x3d files 
> are imported in a scene because
> then we can easily see the size difference between objects in the scene.
> 
I do not agree to this requirement.  It places an undo burden on
implementors and will lower the number of conformant x3d browsers.  All
current X3D browsers would have to be changed significantly to support
this.  If they are allowed to scale to meters internally then they can
give you your units without significant code change.

> In summary, by putting units in an x3d file, browsers recognize coordinates 
> defined by the units (1 1 1 coordinates and cm together, not converted to meter) 
> browsers do not transform scaling for the units when reading the x3d file.
> 
> Does this make sense?
>
not really.  I want units in the file definition.  I don't think the
spec should say anything about how the browser implements units.

-- 
Alan Hudson

President Yumetech, Inc.                               www.yumetech.com
President Web3D Consortium                             www.web3d.org
206 340 8900 ext 111

Open Source CAN be free, as in "free puppy"