Skip to main content

Proposed Java 3D 1.4 API Changes

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

Since today is code freeze for 1.3.2, I thought it would be a good time to update our web pages on 1.4 API development. We have created a Proposed Java 3D 1.4 API Changes page at:

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

Please look this over and give us feedback. If your favorite feature is missing from the list, let us know, although no guarantee it will actually get implemented, since we are hoping to move forward quickly on the 1.4 programmable shader implementation.

-- 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

> What I would really like to do is put more than one texture on a face, where the tex coords for each
> texture are different.

Yes, this is possible in Java 3D. All you need to do is specify the number of texture coordinate sets in the constructor of your GeometryArray, along with an identity mapping array that uses TexCoord set 0 for texture unit 0, TexCoord set 1 for texture unit 1, etc. Then enable two texture units by creating a TextureUnitState object with two textures.

The MultiTextureTest program (in j3d-examples/src/TextureTest) can be used as a starting point for this, but it only uses one set of texture coordinates, so you will need to modify that piece.

-- Kevin

shawnkendall
Offline
Joined: 2003-06-10

I never procedurely (well not NEVER) produce J3D graphs. I get them back from loaders that I have written or got from j3d.org for content creation tools like 3D Studio Max or Maya.

Back when multitexture was first added to J3D (2001?), I added that to our OpenFLT loader, since Multigen's Creator then could export multitextured models (that is muliple textures and UVs per object)

I have been showing this at GDC every year since then. Do not fret, it is a foundation feature in J3D now. :-)

shawnkendall
Offline
Joined: 2003-06-10

More to the topic.

I request:
getParent() be allowed on live/compiled scene graphs.

getLocaltoVWorld() be allowed on NOT live graphs - this one change would great improve the use of J3D graphs for other tasks such as animation drivers and collision systems.

kcr
Offline
Joined: 2004-03-17

> I request:
> getParent() be allowed on live/compiled scene graphs.

Done. The API is in place and is implemented for live graphs. A bit more work is needed before it works on compiled graphs.

> getLocaltoVWorld() be allowed on NOT live graphs - this one change would great improve the use of J3D
> graphs for other tasks such as animation drivers and collision systems.

This is a bit more problematic, but we'll put it on the list to consider.

-- Kevin

shawnkendall
Offline
Joined: 2003-06-10

Removing/deprecating any Capability bits that the current implemention isn't using/checking for live/compile. (whoa allot of /'s)

More abstractly, removing any set/getting feature that isn't actually doing anything behind the scnes and in an effort to make the API easier to use. I am big for making it easier to use, i.e for more adoption.

When J3D was designed, the idea of scene graph compilation was an R & D concept (I even read one of the papers on it :-)), some of the problems it tried to solve are gone or much less now and run-time freedom (dynamic data) is a bigger part of our scenes. Remember when there was NO by-ref in Java3D?

mnjacobs
Offline
Joined: 2003-06-13

Please consider adding support for multiple texture units in the utility primitives (Sphere, Cone, Cylinder,...). Multiple texture units can be used to implement bump mapping (http://mnjacobs.javadevelopersjournal.com/read/1233586.htm). I believe there is enough support in the combine features in 1.3.2 to support diffuse bump mapping otherwise.

Mike

kcr
Offline
Joined: 2004-03-17

Do you have a proposal for how to assign additional texture coordinates? This seems difficult at best for simple, predefined objects like the utility primitives. Perhaps some sort of parameterized representation of the additional coordinates?

-- Kevin

mnjacobs
Offline
Joined: 2003-06-13

Kevin, Because of the utility nature of these objects, I suggest keeping things simple. I propose that all texture units of a primitive object use the same texture coordinates (texure coordinate set 0). This would provide a lot of new function without complicating the primitive API. I think this would be a trival change to Sphere, but I haven't understood the others well enough to tell.

If you think the texture coordinates should differ between texture units, then here's an idea. Perhaps a new flag could be added to the primitive constructors(TEXTURE_UNIT_GENERATE_COORDINATES?)
to indicate that texture coordinate generation be based on the TexCoordGeneration in each of the texture units. I haven't done this, but it would ideal if the user could hook their own texture generation there too.

Mike

kcr
Offline
Joined: 2004-03-17

> Because of the utility nature of these objects, I suggest keeping things simple. I propose that all texture units
> of a primitive object use the same texture coordinates (texure coordinate set 0).

This would be very easy to do. You would just need new constructorors that take the number of texture coordinate sets as a parameter. A texCoordSetMap could be created containing 0 for each element.

-- Kevin

mnjacobs
Offline
Joined: 2003-06-13

Kevin, Because the appearance is needed to designate texture units and the appearance is already part of the constructor, it may be possible to figure out the number of texture units intended by the user through the appearance.

Mike

kcr
Offline
Joined: 2004-03-17

I don't think that inferring it is as clean as making it explicit. Btw, it looks like Box already does what you are describing, so it should be trivial to do it for the others. If you would like to see this done, then submit a JCA, file an issue, and attach a proposed patch. A test program would be a good idea, too.

-- Kevin

pepe
Offline
Joined: 2003-06-10

> It is possible but slower. As you can take a peek at
> PickResult.java and PickIntersection.java on how the
> slower "second pass" of
> pickGeomAllSortedIntersect(pickShape) is done with
> the use of public api.

If picking were done using a pluggable API style, and implemented by default using public API? specialized API would be able to implement different techniques, more or less useable within different domains of application which could be faster than actual one.
Of course, simple picking would be slower (the amount still has to be determined), but due to the non redundancy of calls it might be faster for complete picking if all external.
You might have understood that i'm a strong advocate for taking as much as possible out of the core, but as Java3D has always been said to be inappropriate for some domains, externalizing would be imho the best way to 'versatilize' it much.

guiramos
Offline
Joined: 2004-11-09

hi.
I agree with you, mcneillk and pepe.

In fact, I am studying it(WakeupOnCollisionEntry) right now and really seems to be a nice solution.

And I would like to take a look at that code.
That "extending TransformGroups" idea was very clever.

Thank you.

Guilherme

kcr
Offline
Joined: 2004-03-17

> I am not agree with making Billboard deprecated. OrientedShape is good, but what I should do, if I
> already have part of scenegraph (not a single shape) that I want to be oriented ?

Agreed. We just took this off the list of possible changes.

-- Kevin

kcr
Offline
Joined: 2004-03-17

> As a new feature, i'd see the removal of the power of two texture size requirement. It should be written in
> bold in docs that depending on hardware, texture might be allocated in a greater zone, including all tradeoffs.

I've added this to the list of possible 1.4 features. Btw, non-power-of-two textures are core in OpenGL 2.0 (which isn't readily available), and available as an extension in OpenGL 1.5 (newer NVIDIA cards support this extension, but ATI cards don't).

> We could setup a fast 'compatibility' mode where texture would be stretched into a power of two texture
> and a slower (but of better quality) where UV coordinates would transparently be transformed
> so that they apply to unstretched texture.

I'm not exactly sure what you are getting at here. In any case, I'm not sure that we want to automatically rescale the texture. For one thing it would make texture subimage commands difficult and expensive to implement.

> That, i think, would be a great thing for at least looking glass. When support for non_power_of_two
> is available, texture and their coordinates woul remain untouched.

Yes, this may be a useful feature for Looking Glass. We'll look into it.

pepe
Offline
Joined: 2003-06-10

>I'm not exactly sure what you are getting at here. In any case, I'm not sure that we want to automatically rescale
>the texture. For one thing it would make texture subimage commands difficult and expensive to implement.
That was meant to be a way for anyone to have access to the same 'non power of two' features, but with a compatibility mode for those whose card/driver don't support. (which will happen to most for some time)
You would still use PO2 if you want, all this with the same code path as actually, but if you want to use non PO2 textures without the necessary hardware, you would have to choose what tradeoff to accept for that benefit.
Or maybe i'm complicating and something i've overlooked makes it pointless. If so, please enlight me.

shawnkendall
Offline
Joined: 2003-06-10

On SharedGroups...

Remember you can get much of the memory benefits of SharedGroups w/o actual SharedGroups, by sharing the Geoemtry(Arrays), Appearances and other graph objects. In effect you can make nearly the same shared objects graphs. NEARLY being the key word there. What are the cases where ShareGroups provide concrete extra features over a graph with shared objects?

kcr
Offline
Joined: 2004-03-17

We just removed the proposed deprecation of Collision and WakeupOnAWTBehavior from the list of 1.4 changes. We'll describe their limitations with documentation.

-- Kevin

kimerinn
Offline
Joined: 2003-10-27

> We just removed the proposed deprecation of Collision
> and WakeupOnAWTBehavior from the list of 1.4 changes.
> We'll describe their limitations with documentation.
>
How about SharedGroup? I've readed in 1.4 API changes, that it should be deprecated because it is buggy and hard to implement efficiently. Though it does not improves rendering speed, but it saves a lot of memory (I checked
this loading VRML models with shared nodes). Probably, all rendering optimisations should be throwed away, removing many appropriate bugs. But memory-related optimisations should be left. Such 'light' SharedGroup will be
too useful.

mnjacobs
Offline
Joined: 2003-06-13

Please consider additional support in the area of bounds intersection. (Unless I have missed it somewhere of course.) The current bounds intersection support provides a boolean if there is intersection and leaves it up to the application to determine where the intersection occurred. It would be a big help if there was additional intersection support to return the points that actually intersected. This would aid applications doing geometry changes due to collisions and angular velocity changes due to collisions in rigid body simulations to name a few.

Mike

pepe
Offline
Joined: 2003-06-10

i don't believe this belongs to core. That would be the job of a proper collision API. I think we need to open a path for engines such as ODE to be efficiently coupled and integrated into scenegraph.

jjones7947
Offline
Joined: 2004-10-16

Quality of 3d especially in the games arena is effected heavily by support for shadows. Are gl extensions going to be supported?

shawnkendall
Offline
Joined: 2003-06-10

Since you are asking about gl extension in the context of shadows, I will assume you are looking for depth map textures, one of at least 3 ways to make shadows.
Also you must also mean dynamic shadows, since static shadows can easily be created with multitexture or vertex colors.

Dynamic shadows made from geometry (simple "disks" or projected planar geoemtry) is totally possible in Java3D (we've done it) as most any graphics/scene graph API.

Shadow volumes using the stencil buffer are another way, and that does not require any gl extensions. J3D does not expose the stencil buffer and that was one of the possible changes for 1.4. However... read below

Depth map shadows, using render to texture, also does not require gl extension anymore since everything needed to make it all work is now part of the core OpenGL API.
However, in the case of shadow volumes using the stencil buffer and depth mapped shadows multipass rendering must be employed to make it work. (Actually depth map shadows doesn't really need multipass when multiexture is available, but still an ordered render to texture from the light view then the final scene view must be done and that requires some control mechanism in a scene graph level API.)

So I think the question is, how will the path to shadows be supported, of which there was been a bit of interesting discussion at GDC ;-) (no spoilers, I'll leave that to the J3D team)

But don't let me put words in your mouth, let us know what extension specifically you are lookiing for...

jjones7947
Offline
Joined: 2004-10-16

I posted briefly earlier referencing shadows and support for gl extensions. It's obvious that my knowledge is somewhat dated as I did not know that some of the functionality has been pulled into the opengl core. Let me try to clarify and expand my earlier question.

Some of this will be blatantly obvious to most 3D programmers, but let me say it to establish the context. The bulk of shadows in a game environment can be handled by light mapping. Some kind of dynamic shadow mechanism is needed only with characters as they move about the scene and expose or occlude light sources.

We have been working on loading more and more complex scenes from a custom format out of 3dsMax. The latest challenge was to try and handle pre-rendered light maps(baked). We are using small tileable textures for the base diffuse on set of UV (TexCoords) coordinates and the light maps relied on a second set of UV coordinates.
This would be workable in opengl. Try as we might we could not get J3D geometryArray to use more than one set of texture coordinates per shape. This was necessary because the coordinate sets were different between the diffuse and lightmap textures.

The ability to build a scene and cast light maps is a common element of most 3D level/scene editors (Unreal Ed, GTK Radiant, Qaurck, etc). We need to be able to pull this info into J3D and get it to render correctly. In short we would like to emulate the functionality found here:

http://www.3ddrome.com/articles/dynamiclightmaps.php

http://members.net-tech.com.au/alaneb/lightmapping_tutorial.html

more on dynamic later.

Thanks for the reply and interest,
Jim Jones

Message was edited by: jjones7947

shawnkendall
Offline
Joined: 2003-06-10

"Try as we might we could not get J3D geometryArray to use more than one set of texture coordinates per shape. This was necessary because the coordinate sets were different between the diffuse and lightmap textures."

J3D directly supports multitexture Shape3D's and we've used it in J3D ever since it was available back in 2001. In fact, even before multitexture hardware was standard, J3D did it by internaly performing multipass rendering.

I would suggest searching for some J3D tutorials or picking up the handful of Java3D books. Maybe someone else knows a few good links they can post here too.

Message was edited by: ShawnKendall

jjones7947
Offline
Joined: 2004-10-16

Reference multi-texturing let's make sure we're using it the same way. The ability to have a single but different texture per face is possible. My reading of the docs says that you should be able to do it in one geometry array. Haven't made that work. But can do it by splitting my objects into more than one shape 3d.

What I would really like to do is put more than one texture on a face, where the tex coords for each texture are different. Why different? Because the light map for an object is generally one image having it's own tex coords, while in our use the base textures are small tillables.

The primary reason I have to deal with these less than ideal circumstances is that I am loading info from 3D editors rather than hand building things as Java objects.

I have several books and I've read tutorial/articles/etc with little or no luck. Any recommendations?

nvaidya
Offline
Joined: 2004-08-03

>
> What I would really like to do is put more than one
> texture on a face, where the tex coords for each
> texture are different. Why different? Because the
> light map for an object is generally one image having
> it's own tex coords, while in our use the base
> textures are small tillables.
>

Possible that I don't understand the exact nature of your issue. But it does appear that I have routinely done this kind of modeling with Java3D's multitexture capability. Consider for example the colormapped, animated, lit pulses on the space shuttle here:

http://www.freewebs.com/matspring/ptrackone.htm

The pulses are LineStripArrays under a single Shape3D. Each LineStripArray has 3 multitexture stages and each of those in turn refer to different texture coordinates as below:

Stage 1:
2 Texture Coordinates indexing into a Texture2D colormap. The coordinates are normalized values of a scalar attribute (pressure, density etc.)

Stage 2:
2 Texture Coordinates to model the pulses sliding along the lines using a Texture2D alpha map. The Coordinates are normalized time values.

Stage 3:
Anisotropic lighting, exactly the same technique used in hair/fur rendering, based on the Phong model and using a Texture2D and 3 Texture Coordinates and a view dependent texture transform. The coordinates are 3 components of the tangent vector along the lines.

This has been working quite well with Java3D for ages. There were a couple of issues with combine texture modes, but those were fixed by the Team recently.

mcneillk
Offline
Joined: 2005-02-03

I think it would be [b]quite unfortunate to deprecate WakeupOnCollision(Entry...)[/b] because it can still be very useful to applications.

The problem really is that most applications don't exploit the asyncronous potential of the WakeupOnCollision behaviors.

In particular, I have written some compact collision detection (avoidance) code that uses bounding boxes that are (configurably) more voluminous than the objects they encapsulate. This way, WakeupOnCollisionEntry fires well before the geometry itself is in collision with another Shape3D. Along with some code that extends TransformGroup, applications can intercept calls to setTransform(..) and clamp values to avoid collisions.

In addition, typically the problem with WakeupOnCollisionEntry has been that collisions can occur before the behavior can deal with it. With a few extra lines of code (that I would be happy to share) it is easy to calculate within the WakeupOnCollisionEntry if the collision has already occurred (rare case since the bounding boxes have so much margin) and back the object out (using its inertia) in the very next frame which is effectively not noticeable on the screen.

I am currently an observer in the Java3D community, but I believe that WakeupOnCollision should stay in the 1.4 API. I would be willing to maintain it or upgrade it myself given the opportunity.

pepe
Offline
Joined: 2003-06-10

Maybe the collision code should be deprecate in core to be transfered in utils, so that the actual collision code can be used as actually and an opening is made for pluggable collision apis. (let it be ODE or other)
Moving classes could be done to cause no/little damage to applications in short term and let people translate to utils at their rythm.
In that vision, i'd let picking in utils so that it can also be plugged and replaced by an other mechanism.
Then, for 2.0, they can be removed to cleanup a bit and everyone would use the pluggable ones.
1.5 could be a pluggable modification of the API acting as a draft for 2.0.

jada
Offline
Joined: 2004-03-17

>In that vision, i'd let picking in utils so that it can also be plugged and replaced by an other mechanism.

The reason for moving picking into core is for performance.
For example, if a user needs the richness of information provided in the picking util. such as color and normal of the PickIntersection. We have to do the intersection compution twice for each geometry in question; one in core and the other in pick util.

- Chien.

pepe
Offline
Joined: 2003-06-10

on the performance side.. what if the whole picking was moved to utils and using public part of API. Would it be slower/impossible? How would you expect picking to react if done using public api?

jada
Offline
Joined: 2004-03-17

It is possible but slower. As you can take a peek at PickResult.java and PickIntersection.java on how the slower "second pass" of pickGeomAllSortedIntersect(pickShape) is done with the use of public api.

- Chien.

scotthong
Offline
Joined: 2006-05-05

Since this discussion is picking related and is it possible
to support picking if the GeometryArray references to
the J3DBuffer object!

-- Scott

jada
Offline
Joined: 2004-03-17

>Since this discussion is picking related and is it possible
>to support picking if the GeometryArray references to
>the J3DBuffer object!

This is an oversight in the implementation of J3DBuffer. A new issue has been filed to track this :

Issue 115 - No picking support for J3DBuffer object.

- Chien.

kimerinn
Offline
Joined: 2003-10-27

I am not agree with making Billboard deprecated. OrientedShape is good, but what I should do, if I already have part of scenegraph (not a single shape) that I want to be oriented ?

pepe
Offline
Joined: 2003-06-10

True. Billboard can't be replaced by OrientedShape.

aces
Offline
Joined: 2003-07-17

A *VERY* important thing :

* Better documentation for non public Java3D classes (and methods too ;) );
* Better documentation (JavaDoc like) in the native C libs (OpenGL at least).
* A document to explain, or at least give a overview, of the MT rendering workflow.

This can help us to give more complex contributions and make this project closer to a Open Source philosophy : no-black boxes.

pepe
Offline
Joined: 2003-06-10

> * A document to explain, or at least give a overview, of the MT rendering workflow.
There is a precise document that was linked some time ago that describes pretty well how things work inside. Grab something heavier than you, attach yourself to it, dig in the text and cry for help if you feel you're lost.
http://swpat.ffii.org/pikta/txt/ep/1224/622/

I agree that J3D is quite a beast. The sources still look like an internal tool but after some time you'll get used to it. I've been contributing a bit recently and added some comments here and there. (even asked for comments to be added at some place, which was done very kindly). If you have problems understanding parts of the code, be sure that the team will help you and be also sure that if you happen to document a bit, everyone will love you for that.
Most of the time, comments missing are those that indicate why something is done in a way and not in an other, which takes some time to guess from sources.

aces
Offline
Joined: 2003-07-17

> > * A document to explain, or at least give a
> overview, of the MT rendering workflow.
> There is a precise document that was linked some time
> ago that describes pretty well how things work
> inside. Grab something heavier than you, attach
> yourself to it, dig in the text and cry for help if
> you feel you're lost.
> http://swpat.ffii.org/pikta/txt/ep/1224/622/
>

Thank you, Pepe.
I will follow your tips about something heavier than me...

But I think would be very important have this kind of document right here, ( java3d.dev.java.net ), not elsewhere...
BTW, Does exist a version with figures ? ;) (Kevin ?)

Alessandro

Message was edited by: aces

scotthong
Offline
Joined: 2006-05-05

Improve documentation on Java3D's View Model.

Java3D's View Model is really complicated. Appendix C
of the Java3D specification provides limited documentation
regarding the mathmatical models on how each view policy
affect the transformation from ViewPlatform to Image Space.
A more comprehensive and easy to understand documentation
on the View Model can be further improved!

-- Scott

pepe
Offline
Joined: 2003-06-10

As a new feature, i'd see the removal of the power of two texture size requirement. It should be written in bold in docs that depending on hardware, texture might be allocated in a greater zone, including all tradeoffs. We could setup a fast 'compatibility' mode where texture would be stretched into a power of two texture and a slower (but of better quality) where UV coordinates would transparently be transformed so that they apply to unstretched texture.
That, i think, would be a great thing for at least looking glass.
When support for non_power_of_two is available, texture and their coordinates woul remain untouched.

[edit] precisions

mikofclassx
Offline
Joined: 2003-07-02

Use of Pixel Buffer Object whenever possible (little driver support at the moment, but situation is improving).

kcr
Offline
Joined: 2004-03-17

> Use of Pixel Buffer Object whenever possible (little driver support at the moment, but situation is improving).

This is now on the list of possible enhancements not needing API changes:

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

-- Kevin

kcr
Offline
Joined: 2004-03-17

I just added a page for features that don't require API changes, but which we want to track.

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

Please review and send comments.

-- Kevin

pepe
Offline
Joined: 2003-06-10

One feature misses a lot to me, that is depth buffer test. RenderingAttributes should have NEVER, ALWAYS, LESS,
LEQUAL, EQUAL, GREATER, GEQUAL and NOTEQUAL depth test.
I would love to see that little addition to 1.4 specs.
Depending on how far it needs to be down in the engine, i propose to implement myself. Just tell me so.

I don't agree on the 'collision' deprecation. Now that the code is done and works, why removing it? Even if it is not useful to lots, i believe it is mostly useful for newbies. We need more utilities for newbies so that they can enter rapidly and use j3D successfully.

WakeupOnAWTBehavior also should not be deprecate imho. It is very explicit on what it does, contrarly to WakeupOnBehaviorPost. Why not using wakeupOnBehaviorPost under the hood instead? I do not understand the misnaming for collisions, but for sure that one is pretty well called. Moreover, deprecating this class will cause modifications to other classes (deprecation? recoding?)
Can't also the bugs be solved instead? IF i get to know what they are, i can go down that way and fix.

kcr
Offline
Joined: 2004-03-17

> One feature misses a lot to me, that is depth buffer test. RenderingAttributes
> should have NEVER, ALWAYS, LESS, LEQUAL, EQUAL, GREATER, GEQUAL and NOTEQUAL depth
> test. I would love to see that little addition to 1.4 specs. Depending on how far it
> needs to be down in the engine, i propose to implement myself. Just tell me so.

I just added this to the list of possible (medium-priority) 1.4 features. If you want to take a stab at implementing it, I can give you a quick run-down of what you will need to do. It shouldn't be too difficult.

> I don't agree on the 'collision' deprecation. Now that the code is done and works,
> why removing it? Even if it is not useful to lots, i believe it is mostly useful
> for newbies. We need more utilities for newbies so that they can enter rapidly and
> use j3D successfully.

It is precisely the new users of Java 3D that I want to discourage from attempting to use collision. For one thing, collision is misnamed and is a source of confusion and frustration -- the term "collision" in the industry has come to mean "collision avoidance", which Java 3D does not do. What we do is after-the-fact "collision detection" with no guarantee that the detection will even happen. When users discover this, they typically abandon Java 3D's collision, but not after investing wasted time. Btw, we aren't saying that we are going to remove it, By deprecating it we will warn users that it isn't the preferred way to do what they are probably trying to do.

> WakeupOnAWTBehavior also should not be deprecate imho.

I can see your point. I'll respond to this in a separate post, since I'm out of time for today.

-- Kevin

pepe
Offline
Joined: 2003-06-10

> "Add a new attribute for depth test function to RenderingAttributes: public get/setDepthTestFunction(int function) methods that takes as values one of: ALWAYS, NEVER, EQUAL, NOT_EQUAL, LESS, LESS_OR_EQUAL, GREATER, GREATER_OR_EQUAL. The default value would be LESS_OR_EQUAL for backward compatibility."
GL uses LESS as default, which ought to be the default one for J3D also, imho. Was really J3D using LEQ?

>If you want to take a stab at implementing it, I can give you a quick run-down of what you will need to do. It shouldn't be too difficult.
I'm ready, listening. Go, go, go... :)

For the collision avoidance, well, if people can't read manual, there's nothing we can do. There is nothing in the api docs that give any argument to avoidance and behaviors are explicit in that they only detect collision when it occurs. If people don't take time to be sure of what they get before investing, they only can blame themselves imho. There is no reason to feel faulty for them.
Anyway, collision avoidance in core would of course be fantasticabulous for those that need it. Just to satisfy my curiousity; why wasn't it specified and implemented?

kcr
Offline
Joined: 2004-03-17

>> "...The default value would be LESS_OR_EQUAL for backward compatibility."
> GL uses LESS as default, which ought to be the
> default one for J3D also, imho. Was really J3D using
> LEQ?

J3D uses LEQUAL for default (yes, I know OpenGL uses LESS). For ordinary, non-ordered-group, retained-mode rendering it doesn't matter, so one could argue that LESS may have been a slightly better choice. For rendering co-planar objects using ordered or decal group, or for mixed-mode rendering, LEQUAL seems a better default. Unless there is a compelling reason to change this, we will leave the default as LEQUAL.

>> If you want to take a stab at implementing it, I can give you a quick run-down of what you will need to
>> do. It shouldn't be too difficult.
> I'm ready, listening. Go, go, go... :)

I'll send you some e-mail off-line (probably not until next week, since GDC starts tomorrow).

> For the collision avoidance, well, if people can't read manual, there's nothing we can do.

Ordinarily, I'd agree with you. The problem with this feature is that almost everyone who uses it runs into these issues. Even if we end up not deprecating it, we will need to at least enhance the documentation to make it very clear that: A) this is not collision avoidance; and B) detection is not guaranteed.

Another concern is that collision as defined really doesn't belong in core -- at least not the way it is defined/implemented as behavior wakeup criteria. This may cause some difficulties when moving to a more pluggable system in 2.0. I'm curious to know how many applications actually use collision.

> Anyway, collision avoidance in core would of course be fantasticabulous for those that need it. Just to
> satisfy my curiousity; why wasn't it specified and implemented?

This would be a very difficult feature to implement in a general manner. In the absence of a physics system, there really isn't a good way to do it in a general manner. At a minimum, it would require the ability to "roll-back" or "undo" transform changes, and even that is insufficient. if In any case, this sounds like a good candidate for a utility package.

-- Kevin

pepe
Offline
Joined: 2003-06-10

>J3D uses LEQUAL for default (yes, I know OpenGL uses LESS). For ordinary, non-ordered-group, retained-mode rendering it doesn't matter,
> so one could argue that LESS may have been a slightly better choice. For rendering co-planar objects using ordered or decal group, or for mixed-mode rendering,
> LEQUAL seems a better default. Unless there is a compelling reason to change this, we will leave the default as LEQUAL.
Agreed. I understand.

> I'll send you some e-mail off-line (probably not until next week, since GDC starts tomorrow).
I won't move. Have fun at GDC.

> I'm curious to know how many applications actually use collision.
I do, at least there is someone. I found it convenient for a little app that i use to simulate mosaic creation on 3D objects. I use collision to detect if a piece of mosaic intersects an other when i put it on the object. It's perfect for that kind of job.

nikolai
Offline
Joined: 2003-06-10

What about the minimal JOAL sound implementation you talked about, should that not be in the list?...please :)