I think this is a "1.0"-feature. We cannot speak of a stable 1.0 API when it's that inconsistent like the model loaders interfaces as they are now. So I really think this point is better nested on the 1.0 dev-plan like it already is.

Quote

Since FengGUI already aims for kind of general purpose GUI, I would suggest to keep the HUD at a minimum. Just some textured Frames with buttons and a simple text input. Maybe scrollable surface and/or lists at most. No fancy widgets like trees and such, no layout managers, no xml description language. Just a quick way to make start-screens, highscores, inventories etc.

Maybe this text would be better:Since FengGUI aims at rich GUI applications, the HUD should be kept at a minimum, which is needed to create GUIs for games: Static Widgets like Buttons, TextFields, Labels,, Images, RadioButton, Checkboxes, Lists, Tabs, Panels, Frames... the most basic Widgets needed to make start-screens, highscores, inventories, etc.No need for fancy Widgets like Menus or Trees.

Quote

I want to be able to track the position of an object in a small overlay on my screen. I want to be able to explore the Appearance of a Shape3D. I want to know what are the incoming events. In real-time (Re-use onyx appearance editor ?)

I think, this is a job for a small Swing application.

Quote

4. Java shell

BeanShell is a very good one.

Quote

1. Display Lists

I'd prefer flags, too

Quote

Niwak (vincent) mentioned a bug in the atom sorting algorithm. This has to be "sorted out" and fixed.

This is an urgent bugfix needed in 1.0, too. So I think it's not a "2.0"-feature.

Quote

Who knows a friendly software engineer ?

Am I friendly? Well, at least I have some knowledge on Software Engeneering.

The dev-plan shouldn't include points about bug fixing. Bug have to be bixed in version 1.0. When we have a stabe and clean API 1.0 with no known bugs, we can proceed with 2.0.

I want to be able to track the position of an object in a small overlay on my screen. I want to be able to explore the Appearance of a Shape3D. I want to know what are the incoming events. In real-time (Re-use onyx appearance editor ?)

I think, this is a job for a small Swing application.[/quote]I don't think so having such a feature in Xith3D would be really cool. Remember, people want it all in one lib. I have complex ideas about how this "watching" system would work (either the interface is build in a default way, by class introspection, or it's custom-built by a function implemented by the Watched object's class).Maybe you don't see the interest right know but it *must* be really useful.

Why. And what do you mean by realtime? Isn't displaying the scenegraph and its properties what you want? So why do you need realtime? You catch rendering "events" in a way we need to offer by adding interfaces for this purpose and update the outline. I think Swing can do the job quite well.

Slightly off-topic: theres a nice BSD licenced data visualization library I fell in love with recently called Prefuse. There are several demos in the gallery secion that seem to fit for scene graph browsing. See my favority - be pacient, the applet loads very slow - remember to open the sidebar on the right and fiddle with the settings

Why. And what do you mean by realtime? Isn't displaying the scenegraph and its properties what you want? So why do you need realtime? You catch rendering "events" in a way we need to offer by adding interfaces for this purpose and update the outline. I think Swing can do the job quite well.

Not only scenegraph data : remember scenegraph means graphics and I want to watch IA properties, and so on. But maybe you're right a swing application would work.

Model loaders are already a strength of Xith3D : we have many of them. The problem is they all use different interfaces, some are buggy and some not in the toolkit. We have to : * Provide a common interface for static geometry loaders

Please have a look at org.xith3d.loader.base. This is to be considered as come kind of proof of concept, but is also ready to be used and is actually already used in the BSPLoader. I think is is a quite good and a bit better loader base than the one we have now. Maybe we could consider to completely move to it in v2.0.

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