Standards Forum

 

Login Register    
CDB 3.1 Addendum - Textures
Posted: 26 May 2009 01:48 PM  
Administrator
Rank
Total Posts:  9
Joined  2008-05-26

Please post your suggestions and recommendations for this addendum.

File Attachments 
CDB 3.1 Specification Addendum - Textures.doc  (File Size: 540KB - Downloads: 1072)
 
Posted: 12 October 2009 11:17 AM   [ # 1 ]  
Jr. Member
RankRank
Total Posts:  50
Joined  2008-06-20

1.) Runway Contaminant

To make this subordinate texture type useful for training tasks instead of as a simple visual enhancement, a correlated material coded texture must also be available to support braking and other vehicle dynamics as well as proper sensor presentation.  Is there any plan to support this correlated subordinate texture type?

2.) Branch of Service

What subordinate texture skin mechanism is used to differentiate the appearance of a vehicle painted for a specific armed service?  For instance, how would one depict the color, paint, and marking differences between a US MV and CV 22 aircraft?  It would seem that no combination of the defined Uniform, Camouflage, or Airline selector descriptions is appropriate, although Uniform would seem the logical choice if the codes weren’t color based.

3.) Detail Texture

I believe this subordinate texture type needs more definition to fully describe its format since many different approaches are available to represent detail texture.  As it stands in the 3.1 proposal, I believe it is equally unclear in definition as the deprecated 3.0 Bump Map which was replaced with the more specific Tangent-Space Normal Map definition.

 
Posted: 12 October 2009 01:11 PM   [ # 2 ]  
Jr. Member
RankRank
Total Posts:  50
Joined  2008-06-20
ccbrianf - 12 October 2009 11:17 AM

2.) Branch of Service

What subordinate texture skin mechanism is used to differentiate the appearance of a vehicle painted for a specific armed service?  For instance, how would one depict the color, paint, and marking differences between a US MV and CV 22 aircraft?  It would seem that no combination of the defined Uniform, Camouflage, or Airline selector descriptions is appropriate, although Uniform would seem the logical choice if the codes weren’t color based.

Upon further study, I see that this could be covered by the DIS classification code, but that would dictate two different copies of the model geometry I believe.

 
Posted: 21 October 2009 10:18 AM   [ # 3 ]  
Newbie
Rank
Total Posts:  17
Joined  2008-06-12

1) Runway Contaminant

To make this subordinate texture type useful for training tasks instead of as a simple visual enhancement, a correlated material coded texture must also be available to support braking and other vehicle dynamics as well as proper sensor presentation.  Is there any plan to support this correlated subordinate texture type?

This is a valid suggestion that we will consider for future enhancement to the Spec.

3) Detail Texture

I believe this subordinate texture type needs more definition to fully describe its format since many different approaches are available to represent detail texture.

Correct.  We will propose a definition for Detail Texture.

As it stands in the 3.1 proposal, I believe it is equally unclear in definition as the deprecated 3.0 Bump Map which was replaced with the more specific Tangent-Space Normal Map definition.

Brian, is the proposed definition of Tangent-Space Normal Map unclear?  I am surprised because I think the description (format and usage) is complete.

Signature 

Bernard Leclerc, Eng.
Technical Specialist, Database Technologies
Simulation Products and Military Training & Services
CAE

8585 Côte-de-Liesse
Saint-Laurent (Québec)
Canada H4T 1G6
Tél +1-514-341-2000 poste 2062
Fax +1-514-341-7699

 
Posted: 21 October 2009 11:32 AM   [ # 4 ]  
Newbie
Rank
Total Posts:  17
Joined  2008-06-12

Regarding point 2) above, DIS classification codes can be found in SISO-REF-010.  All variants of the Bell/Boeing V-22 Osprey have a DIS Entity Type of 1-2-225-4-17-0-0. There are specific types for models such as the CV-22A (1-2-225-4-17-1-0) or MV-22B (1-2-225-4-17-12-0).

Yes, variants of a DIS entity are different CDB Models.

Note that DIS handles markings using other attributes.  As such, two instances of the same entity (CDB Model) can have different markings (e.g. vehicle number)... but that is not covered by CDB… yet.

FYI… SISO-REF-010 can be found on //www.sisostds.org/ by searching the File Library.

Signature 

Bernard Leclerc, Eng.
Technical Specialist, Database Technologies
Simulation Products and Military Training & Services
CAE

8585 Côte-de-Liesse
Saint-Laurent (Québec)
Canada H4T 1G6
Tél +1-514-341-2000 poste 2062
Fax +1-514-341-7699

 
Posted: 21 October 2009 01:13 PM   [ # 5 ]  
Jr. Member
RankRank
Total Posts:  50
Joined  2008-06-20
ccbrianf - 12 October 2009 11:17 AM

3.) Detail Texture

I believe this subordinate texture type needs more definition to fully describe its format since many different approaches are available to represent detail texture.  As it stands in the 3.1 proposal, I believe it is equally unclear in definition as the deprecated 3.0 Bump Map which was replaced with the more specific Tangent-Space Normal Map definition.

Bernard Leclerc - 21 October 2009 10:18 AM

Brian, is the proposed definition of Tangent-Space Normal Map unclear?  I am surprised because I think the description (format and usage) is complete.

No, that is a mis-communication.  I was simply making the analogy that Detail Texture is as unclear in the current 3.1 proposal as was Bump Map in CDB 3.0.  Since for 3.1 Bump Map was deprecated in favor of the more well defined Tangent-Space Normal Map, I was hoping to avoid the same problem with respect to Detail Texture in 3.1.  I hope that makes the intent of my statement more clear.

 
Posted: 11 February 2010 11:31 AM   [ # 6 ]  
Jr. Member
RankRank
Total Posts:  50
Joined  2008-06-20

While trying to apply the 3.1 addendum Material Textures on 3D Models , we have discovered that, especially for geo-typical material textures, having those textures refer to a composite material table contained in the 603 Model Metadata dataset is problematic.  Conflict resolution for composite material codes is complex when multiple models share material coded textures.  As such, we would recommend that the addendum specify instead a composite material table per texture similar, to the Raster Material dataset, to keep the composite material code namespaces independent and remove the conflict resolution problem.

 
Posted: 11 February 2010 01:11 PM   [ # 7 ]  
Newbie
Rank
Total Posts:  17
Joined  2008-06-12

Very good point Brian, you just pointed out a design issue with the 3D Model Material Texture dataset… the presence of a cyclic dependency between datasets.  To promote texture reuse, it is necessary that a texture does not refer to a specific model and its metadata.

Your suggestion is appropriate; a dedicated texture CMT dataset is necessary here to break this dependency… in a way that is similar to the pair of Terrain Raster Material datasets 005 and 006.

Signature 

Bernard Leclerc, Eng.
Technical Specialist, Database Technologies
Simulation Products and Military Training & Services
CAE

8585 Côte-de-Liesse
Saint-Laurent (Québec)
Canada H4T 1G6
Tél +1-514-341-2000 poste 2062
Fax +1-514-341-7699

 
Posted: 23 September 2010 01:44 PM   [ # 8 ]  
Jr. Member
RankRank
Total Posts:  50
Joined  2008-06-20
Bernard Leclerc - 11 February 2010 01:11 PM

Very good point Brian, you just pointed out a design issue with the 3D Model Material Texture dataset… the presence of a cyclic dependency between datasets.  To promote texture reuse, it is necessary that a texture does not refer to a specific model and its metadata.

Your suggestion is appropriate; a dedicated texture CMT dataset is necessary here to break this dependency… in a way that is similar to the pair of Terrain Raster Material datasets 005 and 006.

This is a major flaw in the design of model material textures in CDB 3.1.  Are there plans to address this in CDB 3.2?

 
Posted: 23 September 2010 03:43 PM   [ # 9 ]  
Newbie
Rank
Total Posts:  5
Joined  2009-10-30

You’re right… an addendum is in preparation for 3.2 to address this issue.