Skip to main content

Java 3D 1.4 Programmable Shaders

76 replies [Last post]
kcr
Offline
Joined: 2004-03-17

I have put a very rough first draft of what we are thinking in terms of programmable shader support in Java 3D 1.4 on the j3d-core project web page. I am posting it now to spark discussion. I have prototyped enough to prove that the basic concepts are workable, but more prototyping is needed.

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

As we mentioned at JavaOne, we plan to do the 1.4 API specification under the auspices of the Java Community Process (JCP). However, we very much want to involve the larger community in API discussions for programmable shaders, so please join in the discussion.

The main things I would like feedback on now are:

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

2) What is the best way to pass in Uniform parameters other than those which automatically track Java 3D state?

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

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

Please add your comments to this thread.

-- Kevin

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

> Have all the new features for programmable shaders been implemented for Java3D 1.4?

We are just finishing up vertex attributes and shader attributes (uniform shader attributes have been tested in an earlier version, but not since we've done the real implementation). Everything else is done. We anticipate a mostly working version by the end of this week. This version will be GLSL-only. A (probably incomplete) Cg version will follow.

-- Kevin

aces
Offline
Joined: 2003-07-17

Sounds good both proposal for passing Uniform parameters and Varying parameters in GeometryArray .

About :
>1. Should j3dAttrName be specified as a type-safe enum or object instead of a String?

There is any problem using String ?

>2. How do we handle passing arrays to the shader, >especially for system parameters such as lights? One >possibility is:
>
>"var" - scalar variable "var"
>"arr[0]" - array element 0 of "arr"
>"arr[1,3]" - subarray composed of elements 1 through 3 of "arr"
>"arr[]" - entire array "arr"

Good! But the passing array name will be parsed and checked, and if errors raise some Exceptions ?

In Varying parameters in GeometryArray issues I also agree with (A) as the best approach.

Matthew Hilliard

My (poor and untested) understanding of nvidia hardware, drivers and and gl
extensions is that you can throw directx assembly (asm) created by cg/hlsl
at the glsl shading mechanisms (using extensions like
NV_vertex_program[|2|3] in place of ARB_vertex_program, and similarly for
fragment_program) and it should more or less run (again, this is
unverified, and there may be significantly more work to this than I think).

The question of dropping cg in favor of hlsl doesn't seem to make much
sense because from the context of opengl, we're only dealing with the asm
created by either--they are pretty much intertwined.

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

Alessandro Borges

...and cgc, the NV cg compiler, translates all HLSL, GLSL and Cg into GPU asm.
There is light open-sourced version of cgc available at NVidia website.

Kevin, J3D 1.4 will embedded a shader compiler, or client will have to install
her/his preferred one, as CG toolkit ?

Alessandro

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/

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

suryad
Offline
Joined: 2005-02-23

Without trying to dilute this highly technical thread, I would like to say that though I am a noob at Java 3D as you will realize from seeing the one thread I ahve started in this forum, all I can say is your efforts are highly appreciated. I am sure there are many people that are waiting for shader capabilities to be included in Java 3D, like me. While I have virtually no idea what you guys are talking about I hope to change that in the next few months so I can actively participate/contribute in this community. THanks.

shawnkendall
Offline
Joined: 2003-06-10

Question on GLSL vs. Cg?

In preping and reveving our GDC demos I am finding less and less support for Cg, espically as compared to CgFX or HLSL.

Anyone got a bead on the community at large settling on HLSL for OpenGL and dropping Cg dev.?

This could greatly simply Java3D dev in the shaders space as well as our demos! (except that I don't know of a Maya HLSL plug-in :-()

Alessandro Borges

Maybe I am wrong, but isn't Cg a twin brother of (DirectX's) HLSL ?
If so, we have support OpenGL's GLSL, and 'almost' support for HLSL throught
Cg.

Alessandro

btw, are you confusing DirectX's HLSL with OpenGL's GLSL ? or it's me :)

> Question on GLSL vs. Cg?
>
> In preping and reveving our GDC demos I am finding less and less support for
> Cg, espically as compared to CgFX or HLSL.
>
> Anyone got a bead on the community at large settling on HLSL for OpenGL and
> dropping Cg dev.?
>
> This could greatly simply Java3D dev in the shaders space as well as our
> demos! (except that I don't know of a Maya HLSL plug-in :-()

__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/

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

shawnkendall
Offline
Joined: 2003-06-10

That is fairly correct except that direct Cg support for authoring is moving to CgFX which is the .fx format from MS and meant to be imported directly to DirectX.

In fact, I can not find any authoring tools that outputs .cg code directly only .fx. The point being that having J3D support loading .cg is moot since the typical cg shader is embedded in the .fx format with all the extra metadata controls NOT supported by J3D (at least not right now, and probably can 't be with huge efforts)

This is as I understand it but I could be off a bit as I am not in direct contact with the tools developers.

I will say that there is at least one GLSL shader authoring tool but no Cg only tools...

Message was edited by: ShawnKendall

For the record, I am not against the Cg development. I am just trying to get a bead on where the tool support is headed which will really drive the choice for most apps, including mine.

Message was edited by: ShawnKendall

kcr
Offline
Joined: 2004-03-17

> 1) I'd expose the shader language, but leave those classes out of javax.media.j3d and put them so some utility package.
> Only base classes/interfaces go to javax.media.j3d like ShaderAppearence oder ShaderProgram.

We'll look into doing this. Even if we do this, we will need internal, package-scope implementation classes in javax.media.j3d for each different type of shader program (e.g., CgShaderProgramImpl, GL2ShaderProgramImpl). The big advantage is that it would not be a visible part of the public API, so it wouldn't take an API spec revision to add a new shader. It might also be cleaner.

-- Kevin

aces
Offline
Joined: 2003-07-17

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 being 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 excellent OpenGL support, except ATi. And I do not believe a costumer using a ultimate 3D application in a cheap low-end vcard.

>Has anyone had a chance to take a look at the preliminary 1.4.0 implementation yet?

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

Alessandro

herkules
Offline
Joined: 2003-06-12

1) I'd expose the shader language, but leave those classes out of javax.media.j3d and put them so some utility package. Only base classes/interfaces go to javax.media.j3d like ShaderAppearence oder ShaderProgram.

This would also allow to create a lot of things w/o polluting the API.

3) Leave DirectX/HLSL out. Not only it throttles down development, it also gives end users a choice they cannot really take. Even experienced Java3D users cannot decide which one to use. Taking into account that Java3D will always be a bit more conservative concerning 'latest stuff'.
Better do the OGL thing right. All other arguments you gave con DirectX are 100% valid.

aces
Offline
Joined: 2003-07-17

Kelvin,

I just build and run Java3D 1.4 & Cg examples (Win version).
:D YES! It works ! :D

Just a minor tip :

Use the CG_BIN_PATH, CG_INC_PATH, CG_LIB_PATH enviroment variables in the build_windows-i586-gcc.xml file. Those variables, I guess, are already defined in a typical cg develop enviroment. Or even a user defined CG_HOME variable.
And foreign users, as me, usually had a different path to installed CG. Something like :
[b]D:\Arquivos de programas\NVIDIA Corporation\Cg[/b]

I resize down the frame size, and the sphere division count and grown the Alpha cycle. I am still using a old GF4 Ti, and I run the examples in a NV30 emulate mode. As expected it was slow (4-9fps). Time for new vcard hehehe. But looks good anyway.

Another tip : in the ObjLoadCg demo the shaders doesnot update the scene, so it seens stoped. I know this happens becouse there is no updates in the scene, and the shaders work out of Java3D threads,
Maybe a wakeup behavior just to refresh the screen/shader...
Of course the -s option to spin also works.

Now I will test the Linux version ;)

Alessandro

Message was edited by: aces

aces
Offline
Joined: 2003-07-17

I works fine on Linux too ;)

There also minor changes in the native Linux build xml file. A'd add a explicit reference to CG_INC_PATH and CG_LIB_PATH. This time I use CgToolkit 1.3 beta.

A strange thing : J3D runtime needs Cg libs in the LD_LIBRARY_PATH even when I run other demos without shaders.

Once again I had to put my ancient GF 4 Ti on NV30 emulate mode to run the Cg demos. Simple add the following line in my /etc/profile :
[b]
export __GL_NV30_EMULATE=1
[/b]
and edit my [b]/etc/X11/XF86Config-4 [/b] file
adding the following line in the device section :
[b]
Option "NvEmulate" "30"
[/b]
and restart X. This steps are also described at NVidia Linux drivers docs.

kcr
Offline
Joined: 2004-03-17

Alessandro,

Glad to hear it works for you. Thanks for taking this for a test drive.

Thanks for the suggestions about the build environment; we haven't spent any time on that, and don't plan to for a while. However, changing the build scripts to point to a different location isn't a long term solution, since we eventually need to be able to build this on a generic build machine and have it work everywhere, regardless of where CG is installed.

ObjLoadCg without the -s should enable OrbitBehavior with mouse (just like original ObjLoad program). Does this not work for you?

-- Kevin (not Kelvin)

Alessandro Borges

You are welcome ;)

Yes, I know the solution I did for ant built is primary and not for general use. As soon I learn more about ant build files I will try to help here.

ObjLoadCG works fine, as expected. But the shaders are updated just when the mouse roll/translate the model. Without interaction there is no shader update. I guess this is because OrbitBehavior is a passive behavior, not forcing unnecessary screen updates, i.e, zero FPS without mouse drag .
For effective shader display this kind of shader demo needs a constant screen update, using a active behavior, as a FPS counter.

Alessandro

sorry about mispelling your name

java3d-interest@javadesktop.org wrote:
Alessandro,

Glad to hear it works for you. Thanks for taking this for a test drive.

Thanks for the suggestions about the build environment; we haven't spent any time on that, and don't plan to for a while. However, changing the build scripts to point to a different location isn't a long term solution, since we eventually need to be able to build this on a generic build machine and have it work everywhere, regardless of where CG is installed.

ObjLoadCg without the -s should enable OrbitBehavior with mouse (just like original ObjLoad program). Does this not work for you?

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

http://www.javadesktop.org/forums/thread.jspa?messageID=41062#41062;

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

---------------------------------
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
[att1.html]

kcr
Offline
Joined: 2004-03-17

> ObjLoadCG works fine, as expected. But the shaders are updated just when the mouse roll/translate the model.

Oh, I see what you were looking for. As you say, "java ObjLoadCg -s" will work, as would adding a non-passive behavior of some sort. Although the scene won't change if there is no movement, since the pattern isn't really random; it's psuedo-random based on the screen space position (xyz) of the fragment.

> sorry about mispelling your name

No worries. I just wanted to avoid any possible confusion, since there was a Kelvin (Kelvin Chung) who used to work at Sun on Java 3D.

-- Kevin

aces
Offline
Joined: 2003-07-17

[i][b]
Keep the shader language itself out of the application code!
[/b]Herkules[/i]

I deeply agree.
The shader coding itself is a hard task. Developer can, or must, use specific tools as FXComposer, RenderMonkey, RT/Shader, etc for shader development. Doing it inside scenegraph code will be slow and not productive. As Herkules happily sad: [i]"The situation may be compared e.g. with texture loading"[/i]. As for texture is better use PhotoShop, the above mentioned tools are better for shade developement. I think Java3D must load the fine tunned shader assembly codes and apply it, period.

But may we need a way to detect the video card model to apply the correct shader, or we will face users trying to run NVidia GPU assembly code into ATI Radeons.

I mean NVidia CG codes in non NVidia GPUs, or even code for a specific, but not available, model.
Message was edited by: aces

poundsmack
Offline
Joined: 2006-05-05

ok i know little about java programming or shaders but i though i would add some kind of input (keep in mind i have little idea as to what i am talking about and may be jsut completly and blatently wrong)

why not do a code merger with opengl? or allow java3d to have some kind of binding ot use the opengl shaders instead of doing your onw implementaion. as opengl is suported on almost all systems it seems to make sence to me...but again i may be way off and have no idea what i am talking about....

or incorperate the OpenGL Shading Language into the java3d code or have an extention to it? http://www.opengl.org/documentation/oglsl.html

shawnkendall
Offline
Joined: 2003-06-10

Hello everyone,
I finally found where the discussion is going for new J3D.

I first have to say that it wasn't the easiest thing to find...I now have 3 different accounts/registrations with Sun for forums.:-(

On topic...
What little there is to review on the shader page looks relatively good. But I really think this is going to come down to some beta implemetation testing. We need to "run in up the flagpole" and see who salutes. We would try as many existing shader set ups as possible.

On another note.
What would be the situation for things like "render to texture"? I ask because this is arguable the best way to make real time shadows and reflections and has been a sorely lacking capability in J3D. Without render to texture and/or stencil buffer access, many shaders techniques will be stunted. Frankly in our world, this has been a deal breaker longer than no shader support...
Now I know using render to texture the way we need to can involves significant render pipeline alteration since it introduces order dependancies in the render execution, but so does OrderedGroup...

Any words on it's inclusion in J3D1.4?

shawnkendall
Offline
Joined: 2003-06-10

Ping...
It's been 5 days... :-)

paulby
Offline
Joined: 2003-06-13

Please bear with us, we are just finalizing the beta release of 1.3.2. We will be back working on 1.4 topics very soon.....

bayblade
Offline
Joined: 2006-02-17

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

I like this idea, but there's a killer problem with it--the hardware (or the vendor's drivers to be specific) is what needs to do the shader language interprestation (not the JVM) if we want this to come out in any semblence of realtime.

An easier technique might be to treat a FragmentShader Node much like a Texture Node, and Shader themselves much like ImageComponents. A VertexShader Node would be more like a Group Node (with a a specific child shader component).
Where the source bytes come from can be from an external file (some util class to load it), or hacked together on the fly from an InputStream, CharSequence or byte array.

The trick then becomes what are valid shader languages? Obviously a GLSL script is of no use in a HLSL environment, and vice-versa. While CG can be ported to both internally via some NVidia support libarary bindings, its not great on non-NVidia hardware.
I suppose in a perfect world one could always invent a new language (or say a Java interpreter for the rendering hardware), but that's got its own problems (JVMs and vector units with no branching or jumping instructions being fundamentally incomaptible architectures, for example), and typically falls to the hardware vendors to implement, which is much easier said than done (i.e. what is their incentive if you'll buy their hardware anyhow?).

I think its reasonable to say GLSL will accomodate MOST situations. CG is easily ported to both HLSL and GLSL; and HLSL is (somewhat) easily ported to CG (even though it may not run as well having done this). If the shader iself is abstracted out as a "block of data" to the underlying framework, perhaps we need not even care. Those running a DX version of j3d can use HLSL and those running a OpenGL version of j3d can use GLSL and the external API can appear identical, and a j3d developer just needs to pay attention to which one he is going to use (which is no more difficult than paying attention to things like alpha channels or vertex lists).

jcouch
Offline
Joined: 2006-02-17

> An easier technique might be to treat a FragmentShader Node much like a Texture Node, and Shader themselves much like ImageComponents. A VertexShader Node would be more like a Group Node

This is basically what the X3D specification did. On Appearance, we added an array of shader nodes. This allowed the user to provide different implementations of a shader in different languages, in order of preference. The browser would then select one that it could run accroding to the underlying hardware and programming API, and off you go. This allows the browser to also support different hardware capability such as the various Shader Model concepts that D3D uses (if you see all the gaming forums they talk about SM 2.0 v SM 3.0 etc).

sam76
Offline
Joined: 2006-02-14

Hello to all, I have tried to make a program to prove shaders in [b]Cg[/b], this worked with verison [u]Java 3D 1.4.0-pre3[/u] but when adapting it to the new interface of [u]Java 3D 1.4.0-build5[/u] gives the following error me:

[i]Java 3D [dev] 1.4.0-build5-experimental 24 Jun 2005 10:20:13 PDT

DefaultShaderErrorListener.errorOccurred:
UNSUPPORTED_LANGUAGE_ERROR: Shading language not supported
canvas = javax.media.j3d.Canvas3D[canvas0,0,0,792x540][/i]

PostData: Excuse by my horrible English, I am Spanish and this text has been translated by google.

Message was edited by: sam76

kcr
Offline
Joined: 2004-03-17

> I have tried to make a program to prove shaders in Cg ...

Now that shaders have been implemented for real, the quick hack that allowed Cg shaders to work in very early 1.4.0 builds has been removed (it no longer worked anyway). Cg shaders are available, but are not built or enabled by default. We also aren't quite done implementing them.

If you want to experiment with Cg shaders, you need to:

1) build Java 3D with Cg enabled:

ant -Dbuild.cg=1 ...

2) Run your program with the global shading language set to Cg:

java -Dj3d.shadingLanguage=Cg MainClassName

Note that if you run this on Windows, you need to have the directory containing the j3dcore*.dll files in your PATH -- even if you have them installed into your JDK.

-- Kevin

jfelrod1960
Offline
Joined: 2003-11-01

As I stated before in a couple of posts, I'm still new to Java3D, programmable shaders, etc. So keep that in mind.

With Java3D 1.4, will it be possible to do general purpose programming on the GPU? (http://www.gpgpu.org)

jfelrod1960
Offline
Joined: 2003-11-01

Is there any problems with using ATI video cards for Java3D shader programming? Seems like I read somewhere here in the forum that Java3D doesn't work well with ATI cards?

kcr
Offline
Joined: 2004-03-17

We have run Java 3D shaders on ATI cards (on Windows) with some measure of success. We would love for someone in the community to help us test this out and let us know what problems they find.

-- Kevin

jfelrod1960
Offline
Joined: 2003-11-01

A couple of questions ...

Have all the new features for programmable shaders been implemented for Java3D 1.4?

I've been playing around with Java3D and I want to get into shader programming. A couple of books I was thinking about purchasing.

http://developer.nvidia.com/object/gpu_gems_2_home.html
http://books.elsevier.com/us/mk/us/subindex.asp?maintarget=&isbn=1558606599

What do you guys think?

shawnkendall
Offline
Joined: 2003-06-10

IMHO the book to start with is the OpenGL shader language book. You'll need it for reference in any case.
http://www.amazon.com/exec/obidos/tg/detail/-/0321197895/103-2956639-947...

jfelrod1960
Offline
Joined: 2003-11-01

> IMHO the book to start with is the OpenGL shader
> language book.

That sounds like a deal. I will get that instead and buy the GPU Gems book at a later time. Thanks!

Thanks Kevin for the update!

Message was edited by: jfelrod1960

shawnkendall
Offline
Joined: 2003-06-10

This probably should be in a new forum or another one I couldn't find but.
What about Mac support for 1.4.0? IMI REALLY needs/wants that. Mac market may be smaller, but game wise it has far less competition as well. Java3D+shaders is a great advance on Mac, while letting us dev on Macs and deploy everywhere :-)

scotty
Offline
Joined: 2004-07-08

I've been reading the Java 3D 1.4: Programmable Shaders web page at https://j3d-core.dev.java.net/j3d1_4/shaders.html. I'm not a Java programmer, but I think there is an error in the code in the Example Usage section. Surely line 7 should be

fragmentShaderSource = StringIO.readFully(fragmentShaderFile);

and not
fragmentShaderSource = StringIO.readFully(fragmentShaderSource);

as currently listed?

kcr
Offline
Joined: 2004-03-17

> I'm not a Java programmer, but I think there is an error in the code in the Example Usage section. Surely line 7 should be
>
> fragmentShaderSource = StringIO.readFully(fragmentShaderFile);
>
> and not
> fragmentShaderSource = StringIO.readFully(fragmentShaderSource);
>
> as currently listed?

Yes, good catch. Btw, the https://j3d-core.dev.java.net/j3d1_4/shaders.html web page is rather out of date. The GLSLShaderTest example programs checked into the "dev-1_4" branch of the j3d-examples project should be used as a sample.

-- Kevin

kcr
Offline
Joined: 2004-03-17

Here is a brief proposal for passing Uniform parameters (ShaderAttributes) to Java 3D shaders. I will be prototyping this in the next several days. Feedback is appreciated

I. New Attributes

Create a new ShaderAttributes object with following new attributes:

Set of Attributes : expressed as (attrName,value) pairs
Set of SystemAttributes : expressed as (attrName,j3dAttrName) pairs

Note that a given attrName may not appear in more than one of the two sets. That is, the Attributes set must not contain any (name,value) pairs whose attrName equals the attrName in any (name,value) pair in the SystemAttributes set.

II. Details

New classes:

public class ShaderAttributes extends NodeComponent

New methods in existing classes:

ShaderAppearance:
public void setShaderAttributes(ShaderAttributes shaderAttributes)
public ShaderAttributes getShaderAttributes()

Methods in new ShaderAttributes class:

1. Attributes Set : explicit, user-specified attributes

Here are the methods for dealing with the (name,value) pairs for user-specified attributes:

public void addAttribute(String attrName, Object value)
public void addAttributes(Map attributeMap)
public void removeAttribute(String attrName)
public void clearAttributes()
public Object getAttribute(String attrName)
public Map getAttributes()

Where value is one of the following types (or an array of one of these types):

Integer
Float
Tuple{2,3,4}{i,f,d}
Matrix{3,4}{f,d}

2. SystemAttributes Set : implicit system-derived attributes

Note that this includes OpenGL state such as ModelView ModelViewProjection, etc.

Here are the methods for dealing with the (name,value) pairs for system attributes:

public void addSystemAttribute(String attrName, String j3dAttrName)
public void addSystemAttributes(Map attributeMap)
public void removeSystemAttribute(String attrName)
public void clearSystemAttributes()
public String getSystemAttribute(String attrName)
public Map getSystemAttributes()

III. Issues

1. Should j3dAttrName be specified as a type-safe enum or object instead of a String?

2. How do we handle passing arrays to the shader, especially for system parameters such as lights? One possibility is:

"var" - scalar variable "var"
"arr[0]" - array element 0 of "arr"
"arr[1,3]" - subarray composed of elements 1 through 3 of "arr"
"arr[]" - entire array "arr"

Alternatively, an object with a string or type-safe enum, a state (scalar, array element, subarray, or entire array), and indices (as needed).

-- Kevin

kcr
Offline
Joined: 2004-03-17

Here is a brief proposal for passing in Varying parameters (in GeometryArray) to Java 3D shaders.

I. New Attributes

Add the following attributes to GeometryArray

VertexAttrSetCount
VertexAttrSet[0..n-1]
VertexAttrSetFormat[0..n-1]
VertexAttrSetMap[0..n-1]

II. Details

New Constructors (also needed in all GeometryArray subclasses):

public GeometryArray(int vertexCount,
int vertexFormat,
int texCoordSetCount,
int[] texCoordSetMap,
int vertexAttrSetCount,
String[] vertexAttrSetFormat,
String[] vertexAttrSetMap)

New methods:

Basically these are duplicates of the non-deprecated set/get TexCoord methods...

public void setVertexAttribute(int index, float attrs[])
public void setVertexAttribute(int vertexAttrSet,
int index, Tuple4f attr)
...
public void setVertexAttrRefBuffer(int vertexAttrSet, J3DBuffer attrs)

III. Issues

1. For GLSL, VertexAttributes[0] is special, in that it is another way of specifying the position (glVertex). Given that the GeometryArray already has a positional coordinate, VertexAttributes[0] is redundant. We need to decide how to handle this. Possibilities include one or more of the following:

A. For GLSL, always map VertexAttributes[j] to glVertexAttrib(j+1).
That is, VertexAttributes[0] would get sent as glVertexAttrib(1),
VertexAttributes[1] would get sent as glVertexAttrib(2), etc.
This mapping would be done under the cover.

B. Provide an offset that specifies the mapping from vertex
attritbue set to glVertexAttrib; VertexAttributes[j] would get
sent as glVertexAttrib(j+offset)

C. Provide a flag indicating whether VertexAttributes[0] is
allocated, stored, and sent to the GL; in this case, it would
be an error to access VertexAttributes[0]

D. Allow the user to use VertexAttributes[0] instead of
coordinate. Note that we would need to relax the restriction
that coordinate is always present, such that either COORDINATE
or VertexAttributes[0] is present.

I believe that choice A is the best approach. It is the easiest to implement, and encourages more portability between GLSL shaders and CG shaders; we already have a user-supplied mapping from vertex attribute set to named parameter, so the user doesn't really even need to know that this offset is happening (other than to know that they can't access VertexAttributeSet[0] in their shader as gl_Vertex). The only possible downside is that it removes a little flexibility that a combination of B and D would provide. However, I still think A is the best choice.

-- Kevin

jfelrod1960
Offline
Joined: 2003-11-01

I'm a newbie with Java3D so keep that in mind when I ask this question. Will it really benefit adding shaders to Java3D? I have been pondering whether to use Java for game development or use another language. I have also looked into compiled Java. Shaders have been very popular in game animation. Any comments?

Matthew Hilliard

At 11:32 AM 12/2/2004, you wrote:
>Will it really benefit adding shaders to Java3D? Any comments?

Absolutely. Bear in mind that while game development gets the most
notoriety in the 3D field, there is a substantial amount of other 3D
visualization that will benefit from shaders as well.

Java is a fine language to develop games in, even 3D ones. John Carmack
considered using Java when he developed Quake 3, but Java at the time
(1998) while close, wasn't up to the task. The Java of 6 years later is a
considerably better option, and there are a number of decent books covering
a number of topics in game development.
I think if you're a newbie, using j3d will be a far better experience to
get your feet wet with than jumping head first into DirectX or OpenGL in
C(#/++), as it provides a decent framework to actually get things up and
running, and not having to worry about all the little details (i.e. you can
focus on the game itself instead of bugs and minor details).

That said, j3d does have its shortcomings and you may find that those
shortcomings are completely out of line with the game you want to develop.

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

jfelrod1960
Offline
Joined: 2003-11-01

I would like to have real time performance from my animations along with the high definition graphics that shaders provide. I decided that I will at least dig into Java 3D a little further. Thank you for your time.

shawnkendall
Offline
Joined: 2003-06-10

Got it all checked out, build with VC7 (bit of hacking to the .xml files for that one since it couldn't find the CG header files right off) and tested out a few vertex cg scripts.
Most excellent!

shawnkendall
Offline
Joined: 2003-06-10

Hey all!
So after building the j3d 1.4 release and CG demos, I managed to hook it up to our viewer. The j3d switch went fine, then I hacked in the example cg appearance set up and wrote up new cg script that can do normal mapping with one of our characters that I set up normal mapping with texture combiners in old j3d 1.3.1.
Here's a snap of the progress. It looks exactly like my old texture combiner way BUT this is all cg H/W accelerated goodenss, so I can change that script around however it like. Mmmm mmmm good.
http://www.imilabs.com/PageImages/Media/j3D-cg-normalmapping.jpg

jada
Offline
Joined: 2004-03-17

Looks really cool! When can we have the next update of JBrawl ? :-)

cheers,

- Chien

herkules
Offline
Joined: 2003-06-12

Whats JBrawl?

shawnkendall
Offline
Joined: 2003-06-10

JBrawl was the working name for the fighting game demo (final name "Underworld Assault") we showed at Sun' booth at GDC 2003 I think it was.
Never release publicly because,
1) it had our little JNI wrapper for controllers and
2) the animation system has no data compression so the "little" game still required large amount of memory. (read demo) :-)

herkules
Offline
Joined: 2003-06-12

ah ok, I think I saw it when we met at J1 2003 :)

aces
Offline
Joined: 2003-07-17

Kevin
just a suggestion:

alongside the current profile choose implementation, add new properties for runtime shader compiling, as
[code]
j3d.CGVP_Profile=arbvp1 | vp20 | vp30 | vp40
j3d.CGFP_Profile=arbfp1 | fp20 | fp30 | fp40
[/code]

As the vcards/drivers/runtime compilers are enhanced, Java3D can support then in a easy way.

kcr
Offline
Joined: 2004-03-17

>just a suggestion...add new properties for runtime shader compiling:
>
> j3d.CGVP_Profile=arbvp1 | vp20 | vp30 | vp40
> j3d.CGFP_Profile=arbfp1 | fp20 | fp30 | fp40
>
>As the vcards/drivers/runtime compilers are enhanced, Java3D can support then in a easy way.

This sounds like a good idea. We could fallback to arpvp1 and arbfp1 if the specified profile is not available (not all profiles are available on all cards).

We'll also need some way of passing in state, since only the arbvp1 profile automatically tracks OpenGL state. I've been thinking that we need to deal with this anyway, since there are some attributes that don't automatically get tracked for Cg or GLSL that the application may want to access, but can't easily pass in programatically (e.g., window size, number of enabled lights). I was thinking of something along the lines of a map object that allows applications to specify a mapping between pre-defined Java 3D state attributes and Uniform variables in the shader language. This would be in addition to allowing the app to pass in values for uniform variables.

-- Kevin

kcr
Offline
Joined: 2004-03-17

I have putback a preliminary implementation of GLSL shaders. This has been tested on NVIDIA (5950 and 6800) under both Linux and Windows and ATI (9800) under Windows, although it doesn't run well on ATI for some reason (maybe a down-rev driver, but I can't upgrade due to the ATI crash problem). I also moved the shader functionality to a new ShaderAppearance subclass.

To build or use this on Windows, you should just need to checkout the latest sources from the "dev-1_4" branch and compile. If you don't have/want the Cg compiler installed, you can go into Attributes.c and comment out the "ENABLE_CG_SHADERS" line. Eventually, I'll clean this up and make it an "ant" property. I also plan to load the CG library dynamically so that it doesn't blow up if it isn't there, but for now, comment it out if you have problems with it.

On Linux, you need to ensure that you have the latest Mesa header files (Mesa 6.2 will work). Specifically, ensure that the version of glext.h in /usr/include/GL defines the GL_ARB_shading_language_100 extension. If it doesn't you need to upgrade or GLSL shaders will not be compiled in. You can copy the glext.h from j3d-core/src/native/ogl into /usr/include/GL if you like. I have updated this with the latest from opengl.org (which is the same version that is included with Mesa 6.2).

Let me know if any of you are able to get GLSL shaders working.

-- Kevin

aces
Offline
Joined: 2003-07-17

Kevin,

I test it in my gf4 ti with debug and seens it re-compiles the shaders each frame.

see console output:

[code]
Java 3D [dev] 1.4.0-pre1-0412111043-experimental 11 Dez 2004 10:43:34 BRST

Java 3D: J3dDebug.debug enabled
Java 3D: concurrent threadLimit = 2
System threadConcurrency = -1
BranchGroupRetained.compile()....
numTransformGroups= 5
numStaticTransformGroups= 3
numMergedTransformGroups= 2
numGroups= 7
numMergedGroups= 2
numShapes= 1
numShapesWStaticTG= 0
numMergeShapes= 0
numMergeSets= 0
numLinks= 0
numSwitches= 0
numOrderedGroups= 0
numMorphs= 0
GLSLShaderProgram_updateNative: create vertex shader program
COMPILE SUCCESSFUL
GLSLShaderProgram_updateNative: create fragment shader program
COMPILE SUCCESSFUL
GLSLShaderProgram_updateNative: link shader program
LINK SUCCESSFUL
GLSLShaderProgram_updateNative: create fragment shader program
COMPILE SUCCESSFUL
GLSLShaderProgram_updateNative: create fragment shader program
COMPILE SUCCESSFUL
GLSLShaderProgram_updateNative: create fragment shader program
COMPILE SUCCESSFUL
GLSLShaderProgram_updateNative: create fragment shader program
COMPILE SUCCESSFUL
GLSLShaderProgram_updateNative: create fragment shader program
COMPILE SUCCESSFUL
...(many more)
[/code]

aces
Offline
Joined: 2003-07-17

It just happens in NVidia NV25, but the rendering is ok and run very fast (210-230 fps in old system).
In NVidia NV30 emulate mode there is no compiling at each frame. The effect looks like NV25 but slow, due the emulation, of course.

Alessandro