Skip to main content

Java 3D 1.4 Programmable Shaders

76 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kcr
Offline
Joined: 2004-03-17

Thanks for the info. Apparently the NV25 doesn't support GL_FRAGMENT_SHADER_ARB. The code doesn't currently check the extension strings, nor does it check for a non-zero return from glCreateShaderObjectARB -- if 0 is returned when creating the fragment shader object, it would try to compile it every time. You probably aren't getting the fragment shader enabled on the NV25. The fragment shader attenuates the pixels based on their distance from the center of the window. To really use GLSL shaders you need NV30 or better.

-- Kevin

aces
Offline
Joined: 2003-07-17

any ideia about how binding shader parameters will work ?

kcr
Offline
Joined: 2004-03-17

> any ideia about how binding shader parameters will work ?

We don't have concrete API defined, but our current thinking is as follows.

1. Uniform Parameters

We will need a new NodeComponent Object for specifying named uniform attributes, probably something like ShaderAttributes. An instance of a ShaderAttributes object would then be set in a ShaderAppearance. This allows the same shader to be used with different values for its uniform attributes. The ShaderAttributes object will accept name/value pairs (e.g., (String,Tuple4f)) to allow an application to pass in values for named uniform shader variables.

In addition to user-provided values for these attributes, shader programs will need to access Java 3D state for those attributes that are aren't automatically tracked by OpenGL and can't be easily passed in programmatically by the application (e.g., window size, number of enabled lights for a particular branch graph). Rather than incurring the overhead (and using up scarce resources) of having Java 3D implicitly pass state into the shader program, using a predefined mapping of Java 3D state to shader variable name, we plan to allow the user to provide this mapping using a map object of some kind to specify the binding between pre-defined Java 3D state attributes (we'll need to define a list) and Uniform variables in the shader language. This would be in addition to allowing the application to pass in explicit values for uniform variables.

2. Varying Parameters

For per-vertex, varying parameters we propose to add methods to GeometryArray to specify a "vertex attribute set", analogous to the existing "texture coordinate set". Instead of a "texCoordSetMap" there will be some sort of vertexAttributeSetMap defined as an array of names rather than an array of integers. This will allow the user to specify the mapping from numbered vertex attribute to named shader variable.

Passing in uniform parameters is the next thing I'll prototype.

On an administrative node, I'm out of the office from tomorrow (the 23rd) through the end of the year. Sun is shutdown the week between Christmas and New Years Day anyway. With the recent checkin of a fix for Issue 5, the only remaining 1.3.2 work that we have planned is some testing and packaging for the upcoming 1.3.2-beta2 release. We plan to start moving more quickly on 1.4 features starting in mid-January.

-- Kevin

shawnkendall
Offline
Joined: 2003-06-10

Hi all and *bump*

Does anyone have a j3d 1.4 (this shader build) for Mac OS X?

My team is planning out our demos for GDC in March and really wants to be able to show on Mac as well as Windows.

The CG toolkit works there and all else, just need those j3d jars and .so's and since we don't exactly have a Mac developer, we're not in a great position to make the build our selves as we did with the Win32 version.

Thanks for any help!

kcr
Offline
Joined: 2004-03-17

> Does anyone have a j3d 1.4 (this shader build) for Mac OS X?

This would be difficult since Apple has not released the source code for their port of Java 3D. Note that both native code and the Java interface code to AWT would be needed. I'm not certain how easy a from-scratch OS-X port would be.

> My team is planning out our demos for GDC in March and really wants to be able to show on Mac as well as Windows.

We have contacted Apple about their involvement in Java 3D for 1.4. If anyone else wants to contact them and express interest, it might help.

-- Kevin

David Grace

Hi Kevin,

Is there a specific link or person at Apple that we should contact?
I'm sure most people on this list would help in lobbying them to support
Java3D 1.4.

David.

-----Original Message-----
From: java3d-interest@javadesktop.org
[mailto:java3d-interest@javadesktop.org]
Sent: Wednesday, 9 February 2005 3:22 AM
To: interest@java3d.dev.java.net
Subject: [JAVA3D-INTEREST] Re: Java 3D 1.4 Programmable Shaders

> Does anyone have a j3d 1.4 (this shader build) for Mac OS X?

This would be difficult since Apple has not released the source code for
their port of Java 3D. Note that both native code and the Java interface
code to AWT would be needed. I'm not certain how easy a from-scratch
OS-X port would be.

> My team is planning out our demos for GDC in March and really wants to
be able to show on Mac as well as Windows.

We have contacted Apple about their involvement in Java 3D for 1.4. If
anyone else wants to contact them and express interest, it might help.

-- Kevin
---
[Message sent by forum member 'kcr' (Kevin Rushforth)]

http://www.javadesktop.org/forums/thread.jspa?messageID=55730&#55730

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

--
Message protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

kcr
Offline
Joined: 2004-03-17

Before I get back to the API discussion, which I plan do starting tomorrow, I wanted to checkpoint what we have done so far. I have just checked in a [b]*very*[/b] preliminary prototype implementation of shaders (with many caveats) into the 1.4 development branch (branch tag: dev-1_4) of CVS.

Note that this is just a starting point. The fact that we have checked this into CVS in no way means that the API will look like what has been checked in. I just thought it would be helpful to have something concrete that we can look at while we are discussing the API.

This prototype is based on the initial API that I proposed back in September, and which you can find described at:

https://j3d-core.dev.java.net/j3d1_4/shaders.html

I have also checked in two simple test programs using that API, a variant of SphereMotion and a variant of ObjLoad that apply a simple vertex shader and fragment shader. The current prototype requires the Cg runtime library to be installed before you can build or run Java 3D.

For those who want to take a test drive, you can do the following:

1) Install the 1.2.1 version of the Cg compiler and runtime library, which can be found on the NVIDIA web site at:

http://developer.nvidia.com/object/cg_toolkit_1_2.html

On Windows you should download "Cg_1.2.1_Setup.exe" which is at: ftp://download.nvidia.com/developer/cg/Cg_1.2.1/Windows/Cg_1.2.1_Setup.exe

On Linux you should download the "Cg_Linux.rpm" which is at: ftp://download.nvidia.com/developer/cg/Cg_1.2.1/Linux/Cg-1.2.1-Linux.rpm

Note that the latest version of the Cg toolkit is 1.3, which may or may not work since we haven't tested it yet.

2) Checkout the 1.4 development branch (branch tag: dev-1_4) of j3d-core, j3d-core-utils, and j3d-examples from the CVS repository on java.net; you will also need the MAIN branch of vecmath (there isn't a dev-1_4 branch of vecmath).

[pre] mkdir j3d14 # you can use any name here
cd j3d14
cvs checkout vecmath
cvs checkout -r dev-1_4 j3d-core
cvs checkout -r dev-1_4 j3d-core-utils
cvs checkout -r dev-1_4 j3d-examples[/pre]

3) build vecmath, j3d-core, and j3d-examples as you normally would.

4) Run either of the Cg shader example programs in j3d-examples/src/CgShaderTest

Note that this version of Java 3D doesn't really support the ShaderProgram object in anything resembling a robust manner. The current hack piggy-backs on the texture sole-user optimization, so the only programs that are going to work are those that look substantially like the demo programs. The appearance with the ShaderProgram must contain a writable texture (ALLOW_TEXTURE_WRITE) and it must be the sole user of the texture object and all other texture state -- don't ask why. :)

I hope that some of you will be able to try out the CgShader example programs.

-- Kevin

kcr
Offline
Joined: 2004-03-17

Rather than responding to individual posts, I thought I'd try to summarize a couple of the issues that have been raised, as well as a couple that we have been thinking of. I plan to individually answer some of the other posts, particularly Shawn's post asking about render-to-texture, etc., next week.

Note: the next two days are holidays (Thanksgiving) in the USA, so I won't be reading any responses to this until Monday.

1. Does the public API need to expose the particular shader implementation (e.g., Cg versus GL2)? If so, should we provide a utility class to select the best/supported choice from among a group of shaders?

Pro: If achievable, this might let app developers more easily select from among a set of shaders.

Con: Not really feasible without defining a new shading language.

PROPOSAL: The core API needs to expose Cg and GL2 shader subclasses at some level, since a Cg shader program and a GL2 shader program are different from one another. I'm thinking that we should provide some sort of method that returns the list of supported shader types (perhaps by returning an array of appropriately typed Class objects). We can also provide utilities that will take a prioritized list of ShaderPrograms (including the text of the Shaders) and return a ShaderProgram that meets the criteria (e.g., highest priority among supported shaders). So I guess what I am saying is that I like the idea of an application providing a list of shaders, one of which is chosen at runtime, but I would like to simplify the core API.

Thinking out loud a bit here, I think any approach will have to deal with the case where a system / graphics card supports more than one shader (e.g., both Cg and GL2). If we allow both shader types to be used in the same application (same VirtualUniverse), that could be somewhat problematic. Or it might be no big deal, but I want to think about it up front.

2. Should we have a new ShaderAppearance class (probably as a subclass of Appearance) to indicate a programmable pipeline versus a fixed-function pipeline?

Pro: Conceptually separates the fixed-function graphics pipeline from the programmable shader pipeline. Makes the implementation easier, since the same Appearance can't alternate between the fixed-function pipeline and the programmable pipeline.

Con: Can't really think of any at the moment.

Either way, we need to define the set of Appearance attributes that are used/not-used with programmable shaders.

PROPOSAL: Create a ShaderAppearance subclass of Appearance that takes takes a ShaderProgram. We would need to define what happens if the ShaderProgram is null (would either not render objects with a null or invalid ShaderProgram or would render them with a default set of attributes -- any color you like as long as it's white with no lighting, no texturing, etc.)

3. Do we need to leave open the possibility of supporting DirectX HLSL?

Pro: better support on more platforms, since some vendors (e.g., ATI) seem to provide more stable DirectX drivers than OpenGL drivers

Con: it takes more resources to support both DirectX and OpenGL versions of Java 3D

Con: some features will continue to be difficult to supply if we have to use a "lowest-common-denominator" approach.

Con: looking forward to Java 3D 1.5/2.0, we will be unable to allow applications to mix OpenGL and Java 3D features (which some apps have requested) without knowing that OpenGL is underneath.

Con: Providing HLSL shader supports encourages the writing of applications that will only run on DirectX.

PLAN OF RECORD: Sun will not provide HLSL support, nor will we port Java 3D 1.4 to DirectX 9; any future DirectX support will only happen if someone in the community steps up to the plate and does the work. Even then, DirectX shader support in the first release of Java 3D 1.4.0 is unlikely to happen.

4. Passing in uniform (per-primitive) shader parameters

In addition to the variables that automatically track Java 3D state, We need some way to pass in values for named attributes. Conceptually, I am thinking of something like the following

[pre] public class UniformShaderParameters extends NodeComponent {
public void setParameter(String name, Object val);
public Object getParameter(String name);
...[/pre]

Then there would be {set,get}UniformShaderParameters methods in ShaderAppearance. Ignore the name, since I've spent maybe 2 minutes thinking about it.

We probably need some sort of String to OpaqueHandle method or class, so we don't have to do the string lookup every time, but maybe that can be internal to the implementation.

5. Passing in varying (per-vertex, interpolated) shader parameters

I haven't really done any more thinking here, other than we probably need something analogous to texture coordinate sets for additional per-vertex attributes.

Has anyone had a chance to take a look at the preliminary 1.4.0 implementation yet? I'd be curious to know whether it works and what your initial thoughts are.

-- Kevin

Alessandro Borges

Kelvin,

about :

>1. Does the public API need to expose the particular shader
> implementation (e.g., Cg versus GL2)? If so, should we provide a utility
> class to select the best/supported choice from among a group of
> shaders?

Your propose sounds good. Since shader capability changes for each video driver version / video card, it's very important to retrieve the supported shader version. It can help application debugging, and avoid tons of headache to Java3D team.
A new shading language would not take the advantage of full HW acceleration, with some (all ? ) functions beeing software emulated.

>2. Should we have a new ShaderAppearance class (probably as a
>subclass of Appearance) to indicate a programmable pipeline versus a > fixed-function pipeline?

Yes !

> 3. Do we need to leave open the possibility of supporting DirectX HLSL?
Too much cons. All today video cards have excelent OpenGL support, except ATi. And I do not believe a custumer using a ultimate 3D application in a cheap low-end vcard.

I plan to build and run Java 1.4 (Linux & Win) this weekend.

Alessandro

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
[att1.html]

kcr
Offline
Joined: 2004-03-17

Now that 1.3.2-beta1 has been released, we are back to working on programmable shaders. I plan to restart the 1.4 API discussion today or Monday. I apologize for the delay, but it took longer than expected to resolve some of the 1.3.2 issues.

-- Kevin

nosuchmethod
Offline
Joined: 2008-06-05

Actually, as an extension of the above, why not just make a java3d class that mimics all the functionality of an Sh like language... (and extends NodeComponent)

The top level ShaderProgram class could be abstract, with an abstract RunShader(...) method that subclasses could implement, but access would be restricted so that said functions could only use the language functions and those supplied to them by the base class..

Essentially, you'd have native shader code that the compiler would reduce to Cg (or whatever)

I don't know if this is actually feasible, but I'm an OO nut; the elegant solutions always look good to me.

herkules
Offline
Joined: 2003-06-12

Hm, I don't think (and I feel to be with Justin in this respect) its possible today to create a common super-language for the different shader language styles out there. And then additionally make it look like Java.

The result would be the least common denominator lacking the coolest and most recent features.

But for nearly the same reason I'd dislike to see different shader languages brought into the core API of Java3D. Keep the shader language itself out of the application code!

The situation may be compared e.g. with texture loading. There are image and texture base classes, but no Java3D texture format. But also not JpegTexture or PngTexture.
The corresponding code is somewhere else, in the utilities.

So I'd like to see Shader and ShaderProgram in the core API, but not CgShader nor HLSLShaderProgram. They can be part of some com.sun.-package.

With that, even my pre-compiler approach would be easy to do (as an optional add-on) as well as everything else discussed here so far.

nosuchmethod
Offline
Joined: 2008-06-05

Well, you guys know the subject better than I do, I'm sure. The topic of standards vs. freedom is never a clear-cut topic anyway, but I suppose you're probably right to leave the shading to the (established) shader languages. Just throwin ideas out there really.

nosuchmethod
Offline
Joined: 2008-06-05

Hey, I just read your draft spec for shaders in j3d... I hafta say it's a relief to hear that there are people working on this (much needed) functionality. I'd like to contribute generally in any way I can, although it will probably require some shader review on my part.

More generally, though, I think it might be prudent to focus not so much on creating glue code for existing (admittedly powerful) shader languages like Cg, but rather to more fully incorporate shader specification, namely by either aligning with or copying a successful high-level shader language like Sh.

My reasoning here is that a shader program actually written in java would be far more integrated into the existing language than external, foreign code. Sh, of course, isn't a java library - it's implemented on top of C++. Nonetheless, I think the syntactical similarities between the two languages might allow a nearly perfect replication of the original spec.

Naturally, there are some disadvantages - and I do think Cg and GL2 support should be available. But J3D is inarguably a high level API - it just seems maybe a high level shader language implementation might be more fitting..

Any comments, criticisms, or suggestions can be emailed to me, or just posted here. If anyone's interested in trying this, I'd love to help out.

As a final note, I think an in-code solution might even allow a simplification of the current proposed class hierarchy.. although now I'm just rambling.

herkules
Offline
Joined: 2003-06-12

What about NOT expressing the different shader languages in the Java3D core API?

My first thought when thinking about shaders was to have a offline compiler converting shader scripts into Java classes that extend ShaderProgram.

While compiling, additional methods could be generated that are related to the shader scripts content, like setting additional parameters.

Maybe there's even more potential for offline optimization, binary distribution, debug support and so on ....

Just my 2c,

- J

Justin Couch

java3d-interest@javadesktop.org wrote:

> My first thought when thinking about shaders was to have a offline compiler converting shader scripts into Java classes that extend ShaderProgram.

That's a really bad thing to do. Shader programming is designed to be
"inside" the hardware, not run on the CPU. As such, they're typically
very short and sharp bits of code with very specific and typically
highly optimised code. Unless you are doing stuff like Brook, you're
going to have a lot of people screaming quite loudly.

--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------
--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

herkules
Offline
Joined: 2003-06-12

> java3d-interest@javadesktop.org wrote:
>
> > My first thought when thinking about shaders was to
> have a offline compiler converting shader scripts
> into Java classes that extend ShaderProgram.
>
> That's a really bad thing to do. Shader programming
> is designed to be
> "inside" the hardware, not run on the CPU. As such,
> they're typically
> very short and sharp bits of code with very specific
> and typically
> highly optimised code.

Hm, I don't think you got me right.

I didn't suggest to compile a the shader script ->content<- into Java code. Just compile a suitable Java class containing the script in the most appropriate form.

E.g. something like

class HerkulesShaderProgram extends com.sun.shader.CgShaderProgram
{
private final String code = "[the actual shader code]";
//or
// private final byte[] precompiledcode = ....
public HerkulesShaderProgram()
{
super( code );
}

/* maybe optionally: */
public setHerkulesSpecificData( ... ) { ... }
}

Many other options are open by this approach, e.g. compiling shader scripts of different flavors (Cg, HLSL ...) into one ShaderProgram, letting the runtime decide which to use best, compile special debug ShaderPrograms, ... e.g.

class HerkulesShaderProgram extends com.sun.shader.MultiDelegateShaderProgram
{
private final CgShaderProgram( CgCode );
private final HLSLShaderProgram( HLSLCode );
...
}

class HerkulesShaderProgram extends com.sun.shader.CgDebugShaderProgram
{
...
}

jcouch
Offline
Joined: 2006-02-17

> I didn't suggest to compile a the shader script ->content<- into Java code. Just compile a suitable Java class containing the script in the most appropriate form.

I don't see any value that this is offering to the end user. It seems like something else to get in the way. Now you have to have an extra development process (an external compiler to deal with the shader) or you have to supply raw source code to the Java3D runtime so that it can compile it. That seems like a really bad design.

Cg and HLSL are sufficiently different enough that there are a lot of problems that are difficult to surmount in even a simple API design. Throw in GLSL into this and things get far worse. It took the X3D group 18 months to come up with a decent design that would allow the declaration of all the different languages with the different runtime systems and not be completely language specific. Unless you are intimately familiar with all of the shader languages and the way they interact with the rendering pipelines, you just don't know how nuts it is trying to get a common API to work across all of them. It's quite a nightmare in fact and we still don't have a lot of the good things that shaders would allow you to do. They're just too different to be able to cover all the bases.

pepe
Offline
Joined: 2003-06-10

Hello.
I'm not into shaders enough to be able to participe. nevertheless, i can propose something. Would it be possible to make the 'spec' a wiki, writable only by those that are registered to the project?

pauldb
Offline
Joined: 2003-08-30

Today, I've had a potential investor turn us down partly because of our use of Java3D: "Heck, they ain't even got shaders". He's the second to do so.

It's casting a shadow over our work.

Let's get shading!
-Paul

ps apologies - I don't mean to dilute the technical discussion on this thread, just voicing my anxiety that shaders be implemented soon.

jcouch
Offline
Joined: 2006-02-17

>Today, I've had a potential investor turn us down partly because of our use of Java3D: "Heck, they ain't even got shaders". He's the second to do so.

Well, you could always shift over to using Xith3D. The porting work is fairly minimal as the API tries to be identical to J3D, with just some differences in the behaviour handling. They have shader support, but it's fairly new - just as every scene graph API that I know of is very new. Even the big APIs like Open Scene Graph, OpenSG etc have only added real shader support in the last 3-4 months. I think your "investors" are looking for buzzword compliance, which doesn't sound like the sort of investors I'd like to have.

Justin Couch

java3d-interest@javadesktop.org wrote:

> 1) Do you feel that this the right basic approach (especially the class hierarchy)? If not, please make suggestions.

In Aviatrix3D, we started with an almost identical class structure to
what you have here. We found it was insufficient for the use of shaders
so we went a little further and more closely followed the way that
OpenGL does it now. More at the end of the email...

In addition we just finished the final version of the shader extensions
to the X3D specification. X3D has to be more like Java3D, in that it has
to cover a lot of different potential underlying APIs (at least OGL and
D3D, but we also have groups using OpenInventor and Performer too). The
completed spec you can have a read of here:

http://www.xj3d.org/extensions/shaders.html

And how we bind OpenGL to those node signatures is here:

http://www.xj3d.org/extensions/shaders_glsl.html

There is also bindings for Cg and HLSL, but they were written by another
guy so don't have them on my site (yet).

The X3D spec is far more high level in that we have 3 basic classes of
shaders - stuff with lots of parts, but a single programmable interface
(GLSL), stuff with just two parts, each with separate programmable
interfaces (HLSL, Cg, GL 1.4 FP/VP) and everything wrapped in a single
file (the .FX file format and friends). These abstractions seemed to
work quite well across the various situations that browsers will find
themselves in.

> 3) Who will win the World Series this year? (just seeing if you are still paying attention)

Australia!

> 4) We plan to add user-definable varying parameters to GeometryArray similarly to Texture Coordinate Sets. Is this sufficient?

Fairly close. We ended up needing 5 methods to do this that covered the
5 basic OpenGL types.

void setAttributes(int index, int size, byte[] attribs, boolean
normalise, boolean signed)
void setAttributes(int index, int size, double[] attribs, boolean
normalise)
void setAttributes(int index, int size, float[] attribs, boolean
normalise)
void setAttributes(int index, int size, int[] attribs, boolean
normalise, boolean signed)
void setAttributes(int index, int size, short[] attribs, boolean
normalise, boolean signed)

Of course, AV3D is much, much closer to the OpenGL APIs than what J3D
can be and so we're pretty explicit about how you set values - for
example setting a per-vertex matrix would require that the user do their
own calls to the 3 or 4 consecutive index values, rather than having the
API manage that for you.

In X3D land, we just went with the 3 most common types - float array
with selectable length (1-4 components) and 3x3 and 4x4 matrices. Since
D3D doesn't have per-vertex attributes, the way the data is passed
through is as extra sets of texture coordinates. The matrix stuff is
harder to deal with that way as now the user has to explicitly deal with
it.

So, back to our node signature for the GL-specific stuff. We have:

Shader

GL14Shader extends Shader
VertexShader?
FragmentShader?

GL14ShaderProgram
String programSource

FragmentShader extends GL14ShaderProgram
VertexShader extends GL14ShaderProgram

GLSLangShader extends Shader
ShaderArguments?
ShaderProgram?

ShaderProgram
ShaderObject*
String[] source

What this allows us to do is use a single shader program and provide
multiple different sets of arguments to it. This is in keeping with
common practice of reusing a single shader as much as possible due to
the extremely high state change costs they have. You can state sort to
keep a single program on the card and just change the arguments to it on
a per-object basis.

There's a lot more detail to it than this, of course, but the basic
model can work reasonably well. The X3D model doesn't allow for
separating the arguments from the object, which I feel is a shame, but I
believe that the same model will work with a HLSL shader easily.

I don't have the most current javadoc online for this as we only push
the stable releases out to the world and we changed the signature a bit
from the last stable release. If anyone wants them to have a look
through, then email me and I'll fire a big zip file your way. It's about
200K total as a zip file.

--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
Turn it or move it, and a new set of arrangements appears... is it
a single light or many lights, lights that one must know how to
distinguish, recognise and appreciate? Is it one light with many
frames or one frame for many lights?" -Subcomandante Marcos
-------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@java3d.dev.java.net
For additional commands, e-mail: interest-help@java3d.dev.java.net

kcr
Offline
Joined: 2004-03-17

Justin: Thanks for the helpful suggestions. I didn't look at shader support in other scene graph APIs (except Xith3D) prior to posting this, but plan to do so in the next week or two.

Comments from others are most welcome, too.

-- Kevin

nvaidya
Offline
Joined: 2004-08-03

Nice idea to involve the community very early in the discussions. Thanks.

Just some quick "think aloud" ones.

1) On the names used for the variable parameters in the draft: GLSL uses the name "attribute" to refer to per-vertex data that can be set from the application, and "varying" as the variables that get passed from the vertex to the fragment shader. So, just to be consistent with GLSL, though there are also other Shader APIs that need to be considered, would we want to call the proposed "Varying Parameters" as actually "Attribute" ?
The keyword Attribute is already quite extensively used in Java3D - so something like "Uniform Variable" and "Attribute Variable".

2) What facilities to let the uniform and attribute variables to be changed dynamically by the application ?
Something like:
setUniformVariable( "uniformName", value ) ?

The current Java3D API doesn't actually need string-based message passing anywhere, correct me if I'm wrong. So, any alternatives here or any need for them at all ?

On the facility for passing "attribute" variable, how so:

- changes to GeometryArray to specify the number of attribute variables ?
- or, just like TextureUnitState, something like ShaderUnitState( :) ) to encapsulate/transfer the attributes ?
- the attributes could be changed on a BY-REFERENCE mode, I guess. So, the GeometryUpdater semantics would also need to be considered.

3. On the question of creating a new class called ShaderAppearance, I'm inclined to go with the idea because it will ensure the integrity of the existing Appearance API during the development of the Shader API.

Message was edited by: NVaidya

jcouch
Offline
Joined: 2006-02-17

> So, just to be consistent with GLSL, though there are also other Shader APIs that need to be considered, would we want to call the proposed "Varying Parameters" as actually "Attribute" ?
> The keyword Attribute is already quite extensively used in Java3D - so something like "Uniform Variable" and "Attribute Variable".

Direct3D doesn't have the concept of per-vertex attributes so there's really no other input about a name to use.

D3D uses a programmer-defined structure that labels fields with given values descriptor. There's a reasonably large set of pre-defined value names: BINORMAL, TANGENT, PIXEL_SAMPLE etc etc. Anything that is not covered in this basic space cannot be directly handled. The way every D3D shader that I've seen, works around this by dumping any extra data in the higher levels of texture coordinates and then interpreting the values appropriately in the vertex shader.

The application programmer then needs to declare this structure and register it with D3D. The shader code also must declare the identical structure so that it can make use of it. That's where the tricky part comes in as the Java3D implementation has to write and declare this structure on the fly to pass through to D3D. It has to make sure all the names match and so forth.

Complicating this process even further is the completely different take that D3D uses about passing state information into the shader, compared to OpenGL. The difference: D3D does not pass _any_ state in at all. Even the basic model view and project matricies are not available to the shader code unless the user explicitly passes them in. In GLSL, all you need to do is use one of the built-in state variables (eg gl_ModelViewProjectionMatrix). This very different model lead to us having to do some very strange arm twisting to the X3D spec, which is going to be just as bad, if not worse for Java3D to deal with.

> 2) What facilities to let the uniform and attribute variables to be changed dynamically by the application ?
> Something like:
> setUniformVariable( "uniformName", value ) ?
>
> The current Java3D API doesn't actually need string-based message passing anywhere, correct me if I'm wrong. So, any alternatives here or any need for them at all ?

It's the only way to interact with them. Using arbitrary numbers is not only not feasible, it's not possible to do. Both D3D and OpenGL use strings to interact wth the shader. You pass it a string with the variable name and it will pass you back an int describing the "index" of the attribute. Index values are not even guaranteed to be zero based, or even sequential. (vertex attribute at index 0 has special meaning in OpenGL - it's used to replace the vertex values made through calls to glVertex()).

> - or, just like TextureUnitState, something like ShaderUnitState( ) to encapsulate/transfer the attributes ?

That's not a particularly good design. You want to have the shader shared across multiple pieces of geometry. It's far better to hvae per-vertex attributes as part of the geometry itself. That makes it easier for to ensure you have enough of them (ie sanity checking) and that you can provide per-geometry values independent of the shader used to render it.

> 3. On the question of creating a new class called ShaderAppearance, I'm inclined to go with the idea because it will ensure the integrity of the existing Appearance API during the development of the Shader API.

What integrity are we talking about? This will be new methods on Appearance, not completely changing the existing Appearance node signature. If you're not making use of these methods, you should never see any difference. I can't see anything wrong with just keeping the shaders on the normal Appearance node.

nvaidya
Offline
Joined: 2004-08-03

> > So, just to be consistent with GLSL, though there
> are also other Shader APIs that need to be
> considered, would we want to call the proposed
> "Varying Parameters" as actually "Attribute" ?
> > The keyword Attribute is already quite extensively
> used in Java3D - so something like "Uniform Variable"
> and "Attribute Variable".
>
> Direct3D doesn't have the concept of per-vertex
> attributes so there's really no other input about a
> name to use.
>
> D3D uses a programmer-defined structure that labels
> fields with given values descriptor. There's a
> reasonably large set of pre-defined value names:
> BINORMAL, TANGENT, PIXEL_SAMPLE etc etc. Anything
> that is not covered in this basic space cannot be
> directly handled. The way every D3D shader that I've
> seen, works around this by dumping any extra data in
> the higher levels of texture coordinates and then
> interpreting the values appropriately in the vertex
> shader.
>
Thanks for the info on D3D - no per-vertex attributes really is wimpy. I'd prefer though that, in general, GLSL should be the over-riding concern.

>
> > - or, just like TextureUnitState, something like
> ShaderUnitState( ) to encapsulate/transfer the
> attributes ?
>
> That's not a particularly good design. You want to
> have the shader shared across multiple pieces of
> geometry. It's far better to hvae per-vertex
> attributes as part of the geometry itself. That makes
> it easier for to ensure you have enough of them (ie
> sanity checking) and that you can provide
> per-geometry values independent of the shader used to
> render it.
I think your presumption here (and that probably because I said TextureUnitState and ShaderUnitState at the same breath) is that the ShaderUnitState is proposed to be set on the Appearance. No, it would be set on the GeometryArray and, hence, its components - the attribute arrays - can be shared just as the other vertex arrays. Now, just as with any extra level of indirection, there are always pros and cons. My interest primarily is in encapsulation of related variables and obviating the need for reconfiguring an existing well tested GeometryArray API by resorting to composition. As an analogy, if you consider the Appearance API, its components can be individually shared with other Appearances, and the Appearance itself acts as a container. Apart from that, from the internal Java side of things, the modification will be one of composition and the basic GeometryArray API will need minimal changes and for setting/getting it would be GeometryArray#getShaderUnitState()#setWhatever(). The cons, however, may be that such gets/sets may need complex callbacks to the parent GeometryArray; or, the changes needed are indeed so minimal that this indirection may be unnecessary.