GeomContainer and Colors

Engines, Libraries and Tools Xith3D Forums
#1

Are the javax.vecmath.Color* objects in common use, or are they to be avoided? They seem a little oddly-designed, (with w, x, y and z used to access the colour components for example) so I’m not sure whether they are intended for use at the moment.

Also, am I barking up the wrong tree by playing around with GeomContainer? Most of the methods just throw UnsupportedFunction exceptions - is it defunct, or just still under active development?

Assuming GeomContainer is the right thing to be playing with, what is the recommended way of getting colour information out of, for instance, a TriangleArray?

#2

Okay, a few more questions:

I’m a bit confused by the Shader order system. How is the order in which Shaders are applied decided, and can I rely on it?

What makes a Shader get applied to a particular atom? I notice a MaterialShader being applied to geometry that doesn’t have a Material associated with it, and a PointShader not being applied when PointAttributes are set. What determines this?

The Java3D docs are, of course, a good guide to the public Xith3D API. Are there any design/developer documents? Are there any significant deviations from the Java3D API that I should know about?

#3

There exists an overview of Xith3D design and differences to Java3D written by David.

#4

Hi,

I can briefly describe the basics of Xith3D State Management.

  1. All shaders applied before rendering Atom. Xith3D state management code tries to minimize number OpenGL state changes, so if shapes A and B that render sequentially share the same shader, it will be applied before rendering A and will NOT be re-applied before rendeing B. Xith3D performs state sorting before rendering atoms, and there are several ways of how to control (completely and partially) this process.

  2. Every shader controls set of OpenGL state variables related to it, so even if no specific attributes explicitly set for some atom, the shader may be called to bring OpenGL state vars to known default state.

  3. Regarding PointShader - unfortunately, it is not implemented in Xith3D for a moment… Maybe I have to implement it faster, but there was no explicit interest in it. Additionally, I was thinking to implement enhanced version of PointShader with support for NV_POINT_SPRITE extension useful for particle systems, but later figured out that only few cards support it.

  4. Unfortunately, there are no developer/design docs for a moment, except generic doc from the post above. If you are interested in developer-specific questions and trying to make changes to Xith3D rendering core, you can ask me. and I’ll try to help you.

Yuri

#5

Thanks Jens and Yuri, I’ll digest all that and see if I get the hang of thiings now. :slight_smile:

#6

Quick parallel-projection question:

View calculates a parallel projection as centered on (0, 0) with a width of 2 units and a height sufficient to maintain canvas aspect ratio. My Java3D API Jump-Start book describes a parallel projection as centered on (0, 0) with both width and height of 2 units. As this is frankly moronic, I’m guessing it is in error?

Or is this a Xith3D-specific deviation from the Java3D API?

#7

In Xith3D, parallel projection maintains aspect ratio. I did not check how it works in Java3D when implemented this in Xith3D, and Java3D JavaDoc AFAIK say nothing about this, so this is matter of test.

Anyway, if we will have to change it to something different, I think we will have to introduce additional projection policy (compatible with one Xith3D has now).

Yuri