The comments are meant to be starting points for discussion and clarification. So you're invited to participate now to the discussion here ! :o)
General
Thu, Mar 18, 1999 |
WG |
While this extension provides much useful functionality for manipulation 3D objects it is recognised that MHEG-5 has no intrinsic "content" on which this functionality can be applied. When 3D objects are referenced it is usually, if not always, the case that the object referenced already provides the feature provided by this class(s). How can this redundancy be reconciled? It is felt this point needs further discussion. |
Thu, Apr 01, 1999 |
Ralf Kubis | The Shape objects content
should provide only a static set of 3D primitives which approximate the target objects
appearence. No interaction, no animation. So this can be done by many standards like 3DS, X3D, DXF, PLG and s.o. X3D-content for instance may contain dynamic components (think thats Your point) but there can be no interaction between a possible X3D world and the MHEG scene at this time. The behavoir of every 3D object should be controlled by the MHEG scene itself and not by a separated, content depend view engine, to get maximum control and a well defined link-able set of events to execute user input depend manipulations. |
1 Floating point values
Thu, Mar 18, 1999 |
WG | The introduction of floating point variables in this extensions is inconsistent with MHEG-5. This may have a significant impact on the MHEG-5 specification. This point needs to be carefully discussed and agreed. | |||||||||||||||||
Thu, Apr 01, 1999 |
Ralf Kubis | 1st suggestion: A solution would be the use of fixpoint arithmetics. An integer value is used to notate a floating point value. The higher bits for the integer value, the lower for the post-decimals. Object of choice is the number of bits for the integer and the fraction. A 16.16 format has enough precision and range for 3D applications. Since integer operations are much faster at the most processing units fixpoint arithmetic is one of the most used speed acceleration techniques in 3D-engines and will be surely performed on cheaply STBs. A problem is the correct interpretation:
The problem that I see is the different notation of the same value (0.5 in the above example) at domains with different fixpoint formats. Is that a genuine problem for MHEG ? 2nd suggestion: (what I prefer) Regarding discussion point 2 below, we can do it without floating point values. The current domain may give the smallest unit for distance, angle, mass, gravity, alpha value and speed. For instance one gram (or what ever) for mass or one millimeter for distances. So every value can be notated by integers. The author has to control the consequences of the rounding errors in his application. Other solutions ? |
|||||||||||||||||
2 Standard units
Thu, Mar 18, 1999 |
WG | In the Standard units clause it is noted that the Category of Units should be part of the extension but the actual units should be defined by the application domain. |
3 Alpha values
Thu, Mar 18, 1999 |
WG | The question was raised " what is the reasoning behind using an Alpha value range 0.0 - 1.0. |
Thu, Apr 01, 1999 |
Ralf Kubis | No further reasoning. Regarding discussion point 2 above the range could be domain depend. For instance 0 - 100 (for a range from 0 to 100 percent transparency) |
4 Sensors
Thu, Mar 18, 1999 |
WG | This sensor object has a fixed size, whereas the objects sensed may be of variable size. |
Thu, Apr 01, 1999 |
Ralf Kubis | To change the size use the transformation attributes/methods of the base class Entity. |
Thu, Apr 15, 1999 |
Ralf Kubis | I see a little performance problem now with non-uniform scaled sphere-sensors (diffrent scale factors for the scale directions). If the engine has to test two deformed sphere sensors to collision, it ends in a big amout of calculation time. Someone who knows a fast collision check for this case. Un-deformed spheres are very fast to check and may approximate special objects much better than boxes. Omitting of spherical sensors would be a big loss. |
5 Fog
Thu, Mar 18, 1999 |
WG | Fog should be attached to the world not to the camera in real life. |
Thu, Apr 01, 1999 |
Ralf Kubis | Fogging by depth depend
(distance from the camera) alpha blending is a usually technique. It's implemented in
hardware since years and controllable by the most low level APIs (OpenGL, Direct3D, ...).
Fogging is often used to limit the sight range to cover abrupt object transitions at
culling operations far away from the viewer. A useful technique for MHEG-3D too. To model
position depend fog, Sensor objects could trigger camera entrances and trigger fogging
calls. To model separate foggy objects like clouds or smoke it is better to use polygonal
Shape objects with transparent textures, maybe with automatic object rotation to the
viewer (camera Entity). But, ... hmmm ... a Fog object in Your sense may be a special Shape content with spatial expansion and its visualisation may be engine depend. |
6 Transformation path
Thu, Mar 18, 1999 |
WG | Path recording features ia a subject that needs further discussion with respect to some MHEG-5 consistency issues. |
7 Collisions
(not posted yet) |
Ralf Kubis | How far we will go with
physical modelling for collisions ? If solid sensors already intersect each other they do'nt collide (what I prefer). If two solid sensors hit each other in the actual transformation, they collide. Then the transformation of some entities has to change to prevent sensor intersections. to be continued ... |