Browsing the source tree I see there are many, many things thare not used because they're not known or things done twice (ex : Angle and Distance Interpolators, implemented the first time by David Yazel and the second time by David Wallace Croft as behaviors), e.g. the stripifier, a whole log system, a system of "properties", an occluding system (is this really used by default ?), an integrated Profiler !!!!, and gosh what's that Octree thing, is it used at all ?

All of that is great but these features have fall in the dark while we could be all using it..

So if someone can contact David Yazel he could explain us what he was just about to do when he exited. So we can do it ourselves, heh ?

I think it would be a good idea to look through the whole code and clean it up. When I worked on the View class two days ago, I found many many unused variables and some kind of strange CamaraMode class (no offense, Will), which could actually be replaced by en Enum. There are some methods returning an Enumeration, where an iterator or direct access to the Vector/HashMap/etc. whould be better. Enumeration is deprecated. There are so many things to be cleaned up. And while we clean it up, we can understand some parts. Maybe eliminate not used/needed classes, rewrite badly grown parts to have it better.

Just to answer your question Amos, no I don't know David Yazel. So I can't help in that point. Sorry.

Yes, i know how this one came in. But why didn't you use normal int for the constants? The private String fields filled by the constructor are never used. Do you have a problem with it, whan I modify it to be a real Enum?

But I think, a class returning a Vector or HashMap or whatever by a method is much more useful than one returning just an enumeration, because you safe coding (only one method infront of at least two or three) and you can make use of

Enumeration is the Iterator pendant. Both offer the functionality to loop over all elements once. As soon as hasNext/hasMoreElements return false, the are useless (except for a pontential deletion of the last element by Iterator's remove method). On the other hand, Iterable allows you to retrieve an unlimited number of Iterators. if every element in a first instance is accessed during a loop, you can get another Iterator and so on. And as long you don't make use of the remove method, it should be fine to have more the one Iterator at a time...

Enumeration is not depricated but the javadoc says:

Quote

NOTE: The functionality of this interface is duplicated by the Iterator interface. In addition, Iterator adds an optional remove operation, and has shorter method names. New implementations should consider using Iterator in preference to Enumeration.

Xith3d has a lot of unused classes. I made an experience of removing about 60%-70% of the code (from package dependency analysis with Eclipse) and i was able to still run the basic examples.

My advice is that this would be a great time do fully rewrite this engine. There are great ideas in it. It's possible to improve it by passing iterators to the Renderer algorithms to make rendering independent of the scene graph data structure and also having the possibility to make a truly generic geom and texture loaders.

It's also a great opurtunity to create full UML documentation for the core of the engine redesign it entirely. It's not possile to work on an engine without documenting it's core very well and then build upon it.

Xith3d has a lot of unused classes. I made an experience of removing about 60%-70% of the code (from package dependency analysis with Eclipse) and i was able to still run the basic examples.

My advice is that this would be a great time do fully rewrite this engine. There are great ideas in it. It's possible to improve it by passing iterators to the Renderer algorithms to make rendering independent of the scene graph data structure and also having the possibility to make a truly generic geom and texture loaders.

It's also a great opurtunity to create full UML documentation for the core of the engine redesign it entirely. It's not possile to work on an engine without documenting it's core very well and then build upon it.

If some others (including me) were willing to do so, would you be involved ?

"If some others (including me) were willing to do so, would you be involved ?"

Sure, im looking for a new engine with the characteristics i described above. Im finishing my math api. It's taking some time because im doing univ exams at the moment but that would be a starting contribution. A solid math api would be very important for a game engine foundation.

After that I would be interested on working on a generic loader that supports skeletal anim and shaders and doing a very simple scripting language similar to Oblivion scriping language. I already have a design for the scripting language. If anyone is interested i can put it on a thread.

PS: Do you guys want to keep the name of the engine. Xith doesn't sound very pro. What about xeon (or zeon?) ? It's the name of the human colony in the matrix movies if i spelled it right.

First, each algorithm is written in a data-structure neutral way, allowing a single template function to operate on many different classes of containers. The concept of an iterator is the key ingredient in this decoupling of algorithms and data-structures. The impact of this technique is a reduction in the STL's code size from O(M*N) to O(M+N), where M is the number of algorithms and N is the number of containers. Considering a situation of 20 algorithms and 5 data-structures, this would be the difference between writing 100 functions versus only 25 functions! And the differences continues to grow faster and faster as the number of algorithms and data-structures increase.

Applying a similar design to a game engine would mean the renderer would not touch the scenegraph structure directly but use an iterator instead or a more complex accessor class. This is also used in the design of JDSL. This would mean the O(M+N) redution in terms in complexity where M would be different scenes graphs (vrml, java3d, a basic scene graph, etc), N different renderes (software trough java2d cool for applets, jogl, other. etc... ) and a much easier time for loaders to build a scenegraph.

Another interesting point to separate the game engine and allow for extension would be a task manager api for the engene that would drive the renderer.

Quote

Extension through Function Objects

The second way that STL is generic is that its algorithms and containers are extensible. The user can adapt and customize the STL through the use of function objects. This flexibility is what makes STL such a great tool for solving real-world problems. Each programming problem brings its own set of entities and interactions that must be modeled. Function objects provide a mechanism for extending the STL to handle the specifics of each problem domain.

I like this idea of puting important algorithms into function objects to manage them. Im working on function objects for my math api that will be used later for the scripting language. It could be applied to the renderer. In the same way a set can use a separate sorting algorithms the render could take advantage of their own separate sorting algorithms to deal with primitives (atoms?) that are read from a scene graph indirectly using an accessor. Another great point to apply extension.

Quote

Element Type Parameterization

The third way that STL is generic is that its containers are parameterized on the element type. Though hugely important, this is perhaps the least ``interesting'' way in which STL is generic. Generic programming is often summarized by a brief description of parameterized lists such as std::list<T>. This hardly scratches the surface!

I tend to agree with this. Parametrized classes is the weakest form of extension but Java supports templates and a lot of other new things that come before xith was made.

An engine needs a good api for collections. Java util apis just do the bare essential and don't provide very flexible implementations and essential data structures like graphs which are needed for the A* algorithm and pathfinding. The JDSL api is very good, made by a group of univ researchers for their book.

Sure, im looking for a new engine with the characteristics i described above. Im finishing my math api. It's taking some time because im doing univ exams at the moment but that would be a starting contribution. A solid math api would be very important for a game engine foundation.

I would be very curious about your math lib, since the idea of separating data structures and algorithms is the main idea behind the math-lib I'm working on. see here for more information. P.S. I'm not using Xith and probably I'm not planning to do so, but I'd be interested in collaboration.

After that I would be interested on working on a generic loader that supports skeletal anim and shaders and doing a very simple scripting language similar to Oblivion scriping language. I already have a design for the scripting language. If anyone is interested i can put it on a thread.

I also implemented character animation system, which can deform a mesh using a skeleton AND allows morh-targets to be applied to it (I use those for mimics and lip-synchronization). You can download a video here. Further, deformation can be either done on the CPU or the GPU, where the techniques are used, I described in my article 'Real-Time Character Animation on the GPU' published in ShaderX^4. I also plan to open source this, if there will be a collaboration with my math-lib... - I don't want to open source all my work if nothing comes back.Finally, I'm glad to say that a paper I wrote last time was accepted for the IVA'06, which deals with a system for authoring agents behavior. It uses an XML-based format, into which every schripting language supported by the the javax.script framwork can be embedded.

"If some others (including me) were willing to do so, would you be involved ?"

Sure, im looking for a new engine with the characteristics i described above. Im finishing my math api. It's taking some time because im doing univ exams at the moment but that would be a starting contribution. A solid math api would be very important for a game engine foundation.

After that I would be interested on working on a generic loader that supports skeletal anim and shaders and doing a very simple scripting language similar to Oblivion scriping language. I already have a design for the scripting language. If anyone is interested i can put it on a thread.

PS: Do you guys want to keep the name of the engine. Xith doesn't sound very pro. What about xeon (or zeon?) ? It's the name of the human colony in the matrix movies if i spelled it right.

Why not change the engine name but then it wouldn't be an evolution and we should start a really seperate project. (If you feel like it, go request it on dev.java.net so that you're sure it get approved within 6 monhts )

First, each algorithm is written in a data-structure neutral way, allowing a single template function to operate on many different classes of containers. The concept of an iterator is the key ingredient in this decoupling of algorithms and data-structures. The impact of this technique is a reduction in the STL's code size from O(M*N) to O(M+N), where M is the number of algorithms and N is the number of containers. Considering a situation of 20 algorithms and 5 data-structures, this would be the difference between writing 100 functions versus only 25 functions! And the differences continues to grow faster and faster as the number of algorithms and data-structures increase.

Applying a similar design to a game engine would mean the renderer would not touch the scenegraph structure directly but use an iterator instead or a more complex accessor class. This is also used in the design of JDSL. This would mean the O(M+N) redution in terms in complexity where M would be different scenes graphs (vrml, java3d, a basic scene graph, etc), N different renderes (software trough java2d cool for applets, jogl, other. etc... ) and a much easier time for loaders to build a scenegraph.

Another interesting point to separate the game engine and allow for extension would be a task manager api for the engene that would drive the renderer.

The second way that STL is generic is that its algorithms and containers are extensible. The user can adapt and customize the STL through the use of function objects. This flexibility is what makes STL such a great tool for solving real-world problems. Each programming problem brings its own set of entities and interactions that must be modeled. Function objects provide a mechanism for extending the STL to handle the specifics of each problem domain.

I like this idea of puting important algorithms into function objects to manage them. Im working on function objects for my math api that will be used later for the scripting language. It could be applied to the renderer. In the same way a set can use a separate sorting algorithms the render could take advantage of their own separate sorting algorithms to deal with primitives (atoms?) that are read from a scene graph indirectly using an accessor. Another great point to apply extension.

The third way that STL is generic is that its containers are parameterized on the element type. Though hugely important, this is perhaps the least ``interesting'' way in which STL is generic. Generic programming is often summarized by a brief description of parameterized lists such as std::list<T>. This hardly scratches the surface!

I also plan to open source this, if there will be a collaboration with my math-lib... - I don't want to open source all my work if nothing comes back.

Please do : there's really many chances for your software to be improved if your open-source it (and there's no sense to open-source it in 4 years just when the technology is widespread, like Id Software is doing). If your API is really interesting (and what I saw makes me say it is) then some people will use it and contributes back.............

Now these projects seems really cool to me and if it's started I want to contribute. But :- I use Xith for my current game and I have no plan to change (takes too much time to port)- I have not as much math knowledge as I wanted.. however as long as I understand your work I can do documentation, which is really important indeed. I can also provide art for demos if needed.

Further, deformation can be either done on the CPU or the GPU, where the techniques are used, I described in my article 'Real-Time Character Animation on the GPU' published in ShaderX^4. I also plan to open source this, if there will be a collaboration with my math-lib... - I don't want to open source all my work if nothing comes back.

That would be nice. I have checked your math lib and will have a closer look at it. When i complete my own math lib it will be GPL too so you can just take anything you want and add to your own. I will post it in these forums when i have something as well as any other contribution like the scripting language im planning.

- I use Xith for my current game and I have no plan to change (takes too much time to port)

Thats ok. Both projects are open-source so we can all benefit with this. I don't have any intention of charging any money code. It's much more interesting to charge money for content than software when creating a game. IMO.

- I have not as much math knowledge as I wanted.. however as long as I understand your work I can do documentation, which is really important indeed. I can also provide art for demos if needed.

That reminds me of another important issue. Is it possible to create a project at dev.java.net for a collection of textures, models and other public domain art sets? It's realy a pain to have to do your own art set just when you want a simple demo to test a scene fo the engine. I think that a public domain collection of textures, 3d models, animations, sounds, music, fonts would solve this problem. Maybe even have a forum just for this so that people can post their free art and submit it to a cvs repo.

- I have not as much math knowledge as I wanted.. however as long as I understand your work I can do documentation, which is really important indeed. I can also provide art for demos if needed.

That reminds me of another important issue. Is it possible to create a project at dev.java.net for a collection of textures, models and other public domain art sets? It's realy a pain to have to do your own art set just when you want a simple demo to test a scene fo the engine. I think that a public domain collection of textures, 3d models, animations, sounds, music, fonts would solve this problem. Maybe even have a forum just for this so that people can post their free art and submit it to a cvs repo.

We began something like that at MagicSpark, but hey our artists just started (~6 months) modelling often I rant at them cause their models are too high-poly and normals are wrong, and all that. It's hosted on a forum so not very convenient. A dev.java.net project would be much better (with subversion).

Should I ask for it or will you do that (if I do I can grant you Owner access right after it get accepted).

Perhaps it would be better to copy all the textures in the linked sites and reorganize them using our own directory structure and naming conventions. We can never know when one of these sites will be down or closed permanently when we need something.

Perhaps it would be better to copy all the textures in the linked sites and reorganize them using our own directory structure and naming conventions. We can never know when one of these sites will be down or closed permanently when we need something.

I agree with you yet we should ask them permission if they're not in public domain / creative commons.

Yes, i know how this one came in. But why didn't you use normal int for the constants? The private String fields filled by the constructor are never used. Do you have a problem with it, whan I modify it to be a real Enum?

A little late, but here's my answer anyway: What you were looking at was a simple Enum design pattern before they were part of the language. The main reason for avoiding int constants when this class was coded is that it allows some errors to be picked up at compile time, much the same reason why ints are still avoided today. I certainly don't have any objections to changing it to be a real enum, thanks for updating the code!

Cheers,Will

theany mis compiler doesn't pick up mistakes at comp is that the compiler doesn't pick up errors it up when

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