Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Scene Graph  (Read 8989 times)
0 Members and 1 Guest are viewing this topic.
Offline zparticle

Senior Member




Thick As A Brick


« Posted 2003-04-04 13:27:25 »

Okay well to help get myself up to speed on the 3D/OGL/LWJGL stuff I have decided to write a scene graph library for LWJGL.

But before I start I want to know if one already exists, I don't want to duplicate effort. If there is already one out there then I'll find another way to get myself going.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2003-04-04 13:55:28 »

I've got a little framework for pumping triangles of different states in the right order in com.shavenpuppy.jglib.renderer.*

That's probably one of the first, deepest, bits of a scenegraph.

Cas Smiley

Offline zparticle

Senior Member




Thick As A Brick


« Reply #2 - Posted 2003-04-04 14:26:22 »

*Giggle* It's interesting the different ways people think about problems. You, at least in this case, seem to think in a bottom up manner. I tend to think in a top down manner.

It would not have occured to me to start were you have suggested. Smiley This code you mentioned is at SourceForge somewhere? Could you post a link to it? Also I don't suppose you have any simple examples that show it being used so I can avoid going down the wrong path while trying to incorporate it?

EDIT: typos
EDIT2: just found the link
EDIT3: however there are no release files in the project Sad

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #3 - Posted 2003-04-04 18:40:15 »

Muhahaha, another confused LWJGL developer encountering the SPGL! Grin

SPGL is more of a technology dumping ground than a client library, from what I can see.  Cas reserves the right to break it at any time, and I personally doubt there'll ever be a formal release from it.  That's not what it's about, at least not at the moment.

But don't let that disuade you - there's some fascinating stuff in there.  Grab a CVS client and pull the code directly.  Think of it as a nightly build... Grin

Hellomynameis Charlie Dobbie.
Offline zparticle

Senior Member




Thick As A Brick


« Reply #4 - Posted 2003-04-05 17:58:17 »

Thanks for the tip. I'm making good progress on the scene graph lib. Thanks to the fact that I'm basing it on the Java3D scene graph. I've been doing an awful lot of reading as I'm sure you can imagine. Especially since I really haven't had any previous 3D experience.

If the code Cas has fits the model I'll just rip it out and put it in my packages so it doesn't get broken in the future if he needs to make a change.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #5 - Posted 2003-04-07 17:31:46 »

Currently, in my scene graph code, for methods that require a point or points be passed into them I'm using the Vector3f class from lwjgl. Was wondering if this would confuse people and if I should make another class named Point3f for this purpose. Then only use the Vector3f class for methods that really need a vector.

Any opinions?

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #6 - Posted 2003-04-07 18:12:18 »

While some might consider it unnecessary "syntactic sugar", I personally prefer it.  If it's a point, call it a point.  If it's a dimension, call it a dimension.  You use a bit more memory for another couple of class files, but it makes more sense IMO.

Hellomynameis Charlie Dobbie.
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #7 - Posted 2003-04-07 21:18:29 »

A point is a point and a vector is a vector. 2 different things that accidentially have the same members. Why not going the vecmath way and deriving Point3f and Vector3f from Tuple3f?

In the end, it is very practical that Matrix4f#transform() can treat them differently.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline zparticle

Senior Member




Thick As A Brick


« Reply #8 - Posted 2003-04-08 13:42:40 »

Okay, looks like I'll have to change the stuff over to Point3f. Two votes for that no votes for the other way so Point3f it is.

Last night was fun I got all the primitives rendering via the scene graph classes. Nice to see the code actually DO something.

LineArray
PointArray
QuadArray
TriangleArray

Of course they are only using the vertex colors and vertex coordinates right now but that will change soon. Need to get these working tonight.

LineStripArray.java
TriangleStripArray.java
TriangleFanArray.java


Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #9 - Posted 2003-04-08 13:47:54 »

Found a link to a nice overview of scenegraphs today on flipcode:

http://www.realityprime.com/scenegraph.php


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zparticle

Senior Member




Thick As A Brick


« Reply #10 - Posted 2003-04-08 13:58:19 »

Yep, that was one of the first things I read before starting this project. Thanks for pointing it out though. Any other resources you find please let me know.

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #11 - Posted 2003-04-08 16:22:26 »

Inventor, OGRE, OpenSceneGraph, .....

I once tried to do a scenegraph in C++ on top of directX. But I failed. I wanted to embed render states directly as nodes (e.g. have TextureNode); to do the sorting, LODing, ... and rendering all in a single graph traversal..... too much at once.

In the end, the complex copy and reuse patterns of subgraphs killed me. If I only had a GC....


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline zparticle

Senior Member




Thick As A Brick


« Reply #12 - Posted 2003-04-08 17:58:32 »

Quote

I once tried to do a scenegraph in C++ on top of directX. But I failed.

Just curious, did you consider it a failure because it was too slow in the end or because it was simply too complex to finish because of all the memeory allocation/deallocation?

I suspect that when I get the first version of this up for people to look at it will be WAY too slow for practicle use. However I'm hoping people here can help me with algorimths to speed up the rendering then we can all use it.


Offline bmyers

Junior Member





« Reply #13 - Posted 2003-04-08 18:18:52 »

Do you have any intention of making your scenegraph API more-or-less compatible with the Java3D API?  It would certainly make it easier for those of us who are currently using Java3D to switch over to a LWJGL-based scenegraph if/when it makes sense.

It would be great to get better performance, smaller footprint, etc., if it didn't require a rewrite of the entire scenegraph and didn't obliterate the other advantages of using Java3D.

Even partial compatibility would be better then incompatibility.  I am fine with replacing all j3d.Point3f's with lwjgl.Point3f's if the interface is fundamentally the same.

And if it isn't the same, then why not?   Wink

But keep up the good work -- Go trailblazers!

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2003-04-08 18:41:53 »

With respect to points and vectors: I found it immensely irritating that the designers of J3D decided that points and vectors are different things and have different methods.

This isn't how it works in maths. A vector is a point is a matrix.

There is in truth only one kind of thing, and that's a 3-tuple, and we called them Vectors because that's their most common use.

Cas Smiley

Offline zparticle

Senior Member




Thick As A Brick


« Reply #15 - Posted 2003-04-08 18:41:54 »

Quote

Do you have any intention of making your scenegraph API more-or-less compatible with the Java3D API?  It would certainly make it easier for those of us who are currently using Java3D to switch over to a LWJGL-based scenegraph if/when it makes sense.


Yes, the plan is to have a scene graph that is used in a way almost identical to Java3D. The package names will be different of course but I'm trying to keep the following as close as possible:

class names
class heirarchy
method names
graph layout (same child/parent relationships allowed in J3D)

There will be a few changes.

First I have, up to this point, left out methods that take primitive arrays for things like Vector coordinates. In the initial version you would use only methods that take arrays of objects.

I haven't come to a firm decision yet but I don't think I'll have a Universe object. You will simply pass any Locale graphs into the renderer to get them on the screen. Also Locales use floats instead of the HighResCoords that J3D uses. My rationale for this is that with the exception of really advanced games like true flight sims the rounding problem won't be that big of deal. If it turns out to be then I/we can add a new Locale type that uses higher precision coordinates.

Quote

It would be great to get better performance, smaller footprint, etc., if it didn't require a rewrite of the entire scenegraph and didn't obliterate the other advantages of using Java3D.


In J3D it appears that the renderer is started inside of the Universe the instance you attach a Locale with a sub-graph. This keeps you from be able to make a renderer that is most efficient for you particular needs. I plan on supplying a few different renders that handle the scene graph in different ways to allow better performance based on the type of scene be rendered. Obviously you will be able to create a new renderer if the supplied ones don't fit your needs.

Since this scene graph is ONLY going to work with the LWJGL OpenGL binding it will be much much smaller than J3D. What is J3D now, 7 megs for the SDK and runtime? Tongue Yeah, this will be smaller. Smiley

It should be easy to port to other graphics libraries though.

EDIT: Keep in mind before I started this I really didn't have any 3D experience. So some of the choice I make may be completely wrong.Smiley

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #16 - Posted 2003-04-08 20:32:44 »

Quote
With respect to points and vectors: I found it immensely irritating that the designers of J3D decided that points and vectors are different things and have different methods.

This isn't how it works in maths. A vector is a point is a matrix.



I cannot agree with that. A point stands for a certain location in space whereas a vector is a direction that has no certain origin and can be located anywhere. That's also how mathematics and physics handle these items.
A thing like a position is very different from a thing like speed. A think like a vertex coordinate is very different from a thing like a normal.

And for they transform differently (applying a translation to a vector absolutely make no sense), they have to be treated differently.

Libs that ignore the difference have sometimes very ugly code when it comes to transform normals.....

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #17 - Posted 2003-04-08 20:44:54 »

Quote

Just curious, did you consider it a failure because it was too slow in the end or because it was simply too complex to finish because of all the memeory allocation/deallocation?


No no, in fact is was VERY fast! No allocations after setup at all.

Judging from today, I over-simplyfied things. Nodes just had a render() method and the graph was meant to be traversed just once during rendering.

I wanted the perfect solution just in the one scenegraph structure. Means it should be able to do the material sorting, culling, reuse of everything, LOD, ...

Additionally I wanted to use both, heap and stack allocation for objects of all kinds.

Now, as I look to existing scenegraphs, they are by far more complex. Event systems percolating changes up and down the graph, separate structures for rendering, dynamic memory management.

I'm afraid I have to admit I was just not good enough.

Another reason was that I had time. So I designed, threw away, designed again, discarded it, ... very painful.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #18 - Posted 2003-04-10 09:51:03 »

There was good info on that topic today on the J3D mailing list. Sounds complicated.

Damn low-level 3D stuff...


Quote

> Date:         Tue, 8 Apr 2003 06:12:22 -0600
> From: "N. Vaidya" <scienfix@hotmail.com>
>
> Would the Indexed Geometry Array with the USE_COORD_INDEX_ONLY
> bit set be comparable in performance to the one using the
> Interleaved format ?
>
> The OpenGL Red Book (3rd edition and OGL 1.2,
> pages 76, 77, 81) seems to imply that the benefits could
> be "implementation dependent" ( I'm assuming that glDrawElements
> is the one used by the Java 3D UCIO format (?) ).

We do use glDrawElements when rendering indexed geometry with the
USE_COORD_INDEX_ONLY attribute set.  It's a significant memory and
performance improvement from indexed geometry without UCIO since we
don't copy the geometry if we can use glDrawElements.

The performance of glDrawElements does have quite a bit of variation
depending upon the OpenGL implementation.  Some cards have vertex
buffers where vertices can be cached on-board.  If the client arrays can
all fit in the vertex buffer then you could get performance comparable
to interleaved arrays.  Otherwise the implementation has to preprocess
and segment the arrays to fit in the vertex buffers, which takes time,
or perhaps it won't use the vertex buffer at all.

The glDrawRangeElements command has better semantics for utilizing
vertex buffers, including enumerants for getting hints about the native
vertex buffer size, but Java 3D doesn't currently use it.

> I have been primarily using the IGA + UCIO + ByRef format, though,
> of course, constrained by memory usage of dynamic high poly count
> apps.

You're probably fine.  Depending upon the app and the OpenGL
implementation, it's quite possible that the various overheads in
rendering a Java 3D scene graph could make the performance difference
between glDrawElements and glDrawArrays with interleaved data fairly
insignificant.  Optimize your biggest performance bottlenecks with the
aid of a good profiler, and address the the geometry array format only
if it becomes clear you can't improve performance anywhere else.

-- Mark Hood

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2003-04-10 16:54:19 »

Largely about to become obsolete with the advent of ARB_vertex_buffer_object.

In reality what Mark Hood's said there is not strictly true. The biggest vertex buffer you're ever likely to find will only hold 16 vertices in it. On T&L cards this is held on the server side; on non-T&L drivers this will be on the client side, if it even has one, and there may still be a small vertex cache on the serverside.

Then you've got the option of calling glDrawRangeElements which basically works out the best strategy for you and should be as fast or faster than any cleverness on your own part; and if you can't call that you may be able to call glLockArraysEXT which is a more brute force approach to the same problem.

The whole idea is to avoid repeatedly transforming geometry and repeatedly copying geometry from one memory location to another and to minimize the amount of geometry that's got to be copied over a bus and to use the fastest bus there is to do it. Complicated? Nah Wink

<edit> Talking out of my arse and confusing AGP DMA buffers with post-transformation cache. What has the world come to. Take no notice of me.

Cas Smiley

Offline Morin

Senior Newbie




Java games rock!


« Reply #20 - Posted 2003-04-11 00:03:28 »

Quote

I cannot agree with that. A point stands for a certain location in space whereas a vector is a direction that has no certain origin and can be located anywhere. That's also how mathematics and physics handle these items.
A thing like a position is very different from a thing like speed. A think like a vertex coordinate is very different from a thing like a normal.

And for they transform differently (applying a translation to a vector absolutely make no sense), they have to be treated differently.

Libs that ignore the difference have sometimes very ugly code when it comes to transform normals.....

When you use different classes for them you have additional code to maintain...

Making a difference between points and vectors by using different classes is actually new to me. I know two solutions, both make no difference at all, both call the thing (which is essentially a 3-tuple) a vector, and none of them produces any 'dirty' code if you know what you are doing.

Solution no. 1 (which I'm using in my engine): There is very very very seldom a case where you do not know if a vector means a position or a direction. Actually I have not yet seen any such case. There are simply two transformation functions, one for points and one for methods.

Solution no. 2 (which OpenGL uses): Very nice, but requires additional CPU time. All vectors are stored as 4-tuples, where the fourth value is 1 for positions and 0 for directions. A transformation is stored as a 4x4 matrix where the rightmost column contains the translation part of the transform. Advantage: You can store the translation in the matrix as well. Also, computing the signed distance of a point to a plane means simply computing the dot product of two 4-tuples.

BTW the ugly code when transforming normals may have another reason: You cannot transform normals the same way as you transform vertices. This only works for either orthogonal or orthonormal transformations (not sure). Otherwise the normals are tilted towards the surface during transformation.
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #21 - Posted 2003-04-11 09:42:30 »

Sure sure - homogenious coordinates are very common in 3D - not only in OpenGL - and vecmath and Java3D deeply rely on them.

Anyway there is a difference between a technically driven design (a vector is a 4tuple, a point is 4tuple) and a semantical design (a vector is a direction, a point is a position).

If you refuse to distinguish vector and point, there consequently shouldn't be a Color class (Color is a 4tuple). And in some cases, it might even make sense to treat colors like points.

It's a matter of taste in the end. I think vecmath is correct and OK for me, but I could live with other solutions as well.

BTW, even vecmath isn't completely consequent by keeping these things apart.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline zparticle

Senior Member




Thick As A Brick


« Reply #22 - Posted 2003-04-11 15:26:16 »

A quick update:

The scene graph now has everything (I think) except:

Bounding objects
Sound based objects (I'm leaving these out for now)
Behaviors

This weekend I hope to get each of the geometry objects functioning with all of the different Appearance component objects when rendering.

I realize this is a lot to ask but since I'm such a newbie to this stuff I was wondering if some folks would be willing to help me write little test programs to make sure everything is working correctly. After I have a testable version of course. The problem is I can infer certain thing but I have no way of knowing if the render results I get are actually what should happen.

Offline zparticle

Senior Member




Thick As A Brick


« Reply #23 - Posted 2003-04-13 03:38:06 »

No takers huh?

Oh well, how about anyone that would be willing to fill in the code for the Transform3D, BoundingSphere, BoundingPolytope and BoundingBox class methods.

For the Bounding classes the intersects and combine type methods.

The Transform3D class is a boat load of matrix calculations.

One other question, I usually just make what I write free-ware and let people get it from my web site however I think this should be a SourceForge project and under the same open source license as the LWJGL. When there are two projects that are related what is the best way to make sure the package names don't conflict?

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2003-04-13 21:18:58 »

Same way you've always done it - put them in your own domain package (com.scottshaver.*)

Cas Smiley

Offline zparticle

Senior Member




Thick As A Brick


« Reply #25 - Posted 2003-04-14 20:44:10 »

Another small update, if anyone cares...

The following classes are implemented in the com.sas.lwjgl.scenegraph package.

AmbientLight.class, Appearance.class, Background.class, BoundingBox.class, BoundingLeaf.class, BoundingPolytope.class, BoundingSphere.class, Bounds.class, BranchGroup.class, Clip.class, Color3f.class, Color4f.class, ColoringAttributes.class, DecalGroup.class, DirectionalLight.class, ExponentialFog.class, Fog.class, Geometry.class, GeometryArray.class, GeometryStripArray.class, Group.class, ImageComponent.class, ImageComponent2D.class, ImageComponent3D.class, Leaf.class, Light.class, LinearFog.class, LineArray.class, LineAttributes.class, LineStripArray.class, Locale.class, Material.class, Node.class, NodeComponent.class, OrderedGroup.class, PointArray.class, PointAttributes.class, PointLight.class, PolygonAttributes.class, QuadArray.class, RenderingAttributes.class, SceneGraphException.class, SceneGraphObject.class, SceneGraphRuntimeException.class, Shape3D.class, SpotLight.class, Switch.class, TexCoordGeneration.class, Texture.class, Texture2D.class, Texture3D.class, TextureAttributes.class, Transform3D.clas, TransformGroup.class, TransparencyAttributes.class, TriangleArray.class, TriangleFanArray.class, TriangleStripArray.class

The rendering engines will go in the com.sas.lwjgl.render package and currently only has one class: SimpleRenderingEngine.class

The package com.sas.lwjgl.examples contains example programs. Mainly I'm unsing this to test things with.

The package com.sas.lwjgl.imaging contains classes that can read different image file formats (no dependence on anything coming from Sun except the basic language constructs of course). These must implement the ImageFile interface and there are currently two. TargaFile.class and WindowsBitmapFile.class

Where it stands right now:

I keep thinking I'm ready to deal with the Appearance attribute rendering and then I find something else I've forgotten to create. I think that is almost over. I have a few things to finish up for the Transform3D and Bounds classes, then I need to create the View and ViewPlatform replacement classes and I can focus on the rendering engine. Just remembered I have to go through all of the classes and put in the cloning methods, but this can wait.

Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #26 - Posted 2003-04-14 21:04:50 »

Wow, this is a very impressive list!

Do you re-implement Java3Ds principles or do you have something very different?

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline zparticle

Senior Member




Thick As A Brick


« Reply #27 - Posted 2003-04-14 21:22:48 »

Quote
Do you re-implement Java3Ds principles or do you have something very different?


I think you're asking if I'm following their design Ideology, if so then the answer is, yes as closely as possible. Here is my current readme.txt file perhaps it will shed some light.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
/*------------------------------------------------------------------------
The LWJGL (Light Weight Java Gaming Library) is an open source project to
provide a direct binding to OpenGL for the Java(tm) language. LWJGL is only
intended to provide that low level binding and as such lacks certain tools
that many programmers need to complete their projects.

The LWJGL Scene Graph (LWJGL-SG) is a separate project intended to give
programmers some of those tools. The major focus of the LWJGL-SG is to
provide a scene graph for 3D programs that use the LWJGL. Other utilities
may be included in the library though (such as the imaging package for
loading image files).

This scene graph is based heavily, class architecture wise, on the scene
graph provided in the Java3D API. In fact the initial version of this
scene graph was constructed after reading the book:

The Java 3D API Specification (ISBN 0-201-32576-4)

several times, *sigh*. The book hadn't seen the light of day since I
bought it a long long time ago. By the time I get a first release made
it will probably be totally destroyed. (Note: Because the book is old
many features of the current Java3D API my not be (and probably are not)
present in this library. That's why we have new releases.)

This is an important point, no source code was copied from the Java3D
libraries. In fact the source code was never even looked at (I'm not
sure if it is even available). I chose to base my code on the Java3D
API specification for two reasons.

First, prior to writing this I had basically no experience with 3D
programming. I knew that there was no way I could produce something usable
without having a road map laid out for me. The API specification was my
road map.

Second, I wanted to give Java3D programmers that were considering moving
to the LWJGL the easiest path for the migration I could. Obviously this
scene graph is not going to be an exact copy of the Java3D scene graph.
That was never the intention, but it is similar enough that porting a
Java3D program to it should not be tramatic.

This file is an attempt to describe the areas where this scene graph and
the Java3D scene graph differ.

Scott Shaver (zparticle)
------------------------------------------------------------------------*/


**************************************************************************
Class Differences:

This section is an overview of the main design difference between the
Java3D scene graph classes and the classes in this library.
**************************************************************************

1> Many of the Java3D classes give the programmer to sets of methods for
performing a task, one set that uses object and one set that uses Java
primitive types (usually in arrays). This library has left out the methods
that use Java primitives.

2> Many of the class methods in Java3D get values from the classes by
passing in an array of primitives or objects in the argument list. I
assume the reasoning behind this was so the API programmers could control
when references to the actual values were returned and when copies of the
values were returned. I have choosen to use getter methods that return the
actuall value references. There are two reasons for this.

First, I don't like the other method, java should have constants built
into the language symantics. Second, memory consumption. This library is
intended to be used for games where constant object allocation/garbage
collection is a major no-no.

The implication of this is the following, the programmer is expected to
play nice and not modify the values in the references returned from the
methods. If he doesn'
t follow this rule then he will be spending an
enormous amount of time debugging his code. :)

3> No AWT or Swing. It is important to make sure that no AWT or Swing code
creeps into this library. This library needs to following the lines of
LWJGL and avoid using anything that makes it dependant on AWT or Swing.
Part of the reason for this is the use of compilers that can compile Java
programs into native excutables often don't have the ability to use AWT
and Swing. Another reason for this is simply that it is not neccessary and
therefore why do it.

**************************************************************************
Classes Left Out:

This section lists the classes from the Java3D scene graph that have
been left out for one reason or another.
**************************************************************************

DepthComponent
DepthComponentFloat
DepthComponentInt
DepthComponentNative

All of the audio classes.
All of the Behavior classes.
All of the Pick classes.
The SharedGroup class and Link class.

**************************************************************************
Class Changes:

This section lists the classes from the Java3D scene graph with the same
names in this library that have some fundamental differences.
**************************************************************************


**************************************************************************
Things To Do:

This section lists the things that are not done but should be at some
point.
**************************************************************************

The capability bits for the graph node objects haven'
t been implemented.
The constants and the code in the getter/setter methods need to be added.
When we do this the methods should throw a SceneGraphRuntimeException if
the capability isn't turned on.

----These classes need some of the methods filled in----
Bounds.java
BoundingBox.java
BoundingPolytope.java
BoundingSphere.java
Transform3D.java

The view platform, nothing is done.

Fog - needs the scope methods added
Light - needs the scope methods added

NodeComponent - uncomment the duplicateNodeComponent and cloneComponent methods
Node - uncomment the duplicateNode and cloneNode methods
Implement the cloning methods in the rest of the Nodes and NodeComponents

Offline zparticle

Senior Member




Thick As A Brick


« Reply #28 - Posted 2003-04-15 14:09:06 »

Okay I'm getting geared up to handle the Appearance properties of Shape3D objects in the renderer. I bought an OpenGL reference and have been matching up the gl functions with the properties so I can get an idea of what I have to do while rendering.

Since gl is a big state machine and since the state is going to have to change quite a bit while rendering the scene graph I was wondering what the correct way to save the state of gl is. For instance if I'm traversing the graph and come to a BranchGroup that contains 2 subgraphs I need to push the current state onto a stack and then traverse one of the subgraphs. When that subgraph is finished I need to pop the state off of the stack and then go traverse the other subgraph.

What functions, if any, should I use from OGL to accomplish this? If there are functions for this purpose is there a limit to how deep the stack can get?

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #29 - Posted 2003-04-15 16:57:30 »

Quote
What functions, if any, should I use from OGL to accomplish this? If there are functions for this purpose is there a limit to how deep the stack can get?


Use PushMatrix and PopMatrix to save the current matrix - usually the viewing or modelling matrix.

Use PushAttrib and PopAttrib with a specific flag to save information like lighting settings, line drawing modes, viewport settings etc.  Can also push/pop ALL_ATTRIB_BITS for the shotgun approach!

These stacks do have a maximum depth though, and you'll have an error thrown if you exceed it.  Get the current settings with a GetIntegerv of MAX_MODELVIEW_STACK_DEPTH, MAX_PROJECTION_STACK_DEPTH or MAX_ATTRIB_STACK_DEPTH.  Specifically, the modelview should have a minimum stack depth of 32, projection is at least 2, and attribute is at least 16.

With those limits in mind, you might want to consider restoring state manually, although I expect you'll have a performance hit with that.  Check the limits of current OpenGL implementations and see if it's going to be enough for you.

Hellomynameis Charlie Dobbie.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (26 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (34 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (44 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!