Hi guys, I was looking for the XIN tutorial in cvs but its not there,
Can anyone confirm if its not there?
Bye
Hmmm… yes, it seems to be deleted. Marvin?
Meantime, you can just get it on web:
https://xith-tk.dev.java.net/source/browse/checkout/xith-tk/docs/xin/Attic/xin.pdf?rev=1.5
Thanks bohdan ;D
Well, I deleted the PDF, since it isn’t always current. Please use the OpenOffice document until we release it on xith.org. Exporting it to PDF and committing this everytime Amos or me modified it just increases the repository size.
When Amos added the screenshots he’s talking about, we’ll release it on xith.org.
@Amos: What do you think about splitting XIN into two parts? Part one just explains the very basics to get started with Xith3D, like the current version does. So the current version (together with the screenshots) could be “XIN - Part I” and the following chapters could be summed up in “XIN - Part II”.
Marvin
That would be great for the newbies ;D
Btw. I just read the current version. Thumbs up for this nice tutorial!
Splitting it into two parts, maybe “XIN - Getting Started” and “XIN - Advanced Topics”, seems like a good idea.
Great idea. But what about making it a little more dramatic by using subtitles 
XIN - Part I
Getting Started
and
XIN - Part II
Advanced Topics
I object ! ;D ;D
XIN is supposed to explain Xith “in a nutshell”.
I had the project to co-write (with you, Qudus) a second book named “Xith Under The Hood” (UTH) which explain the low-level scenegraph and renderer structures how precisely it is handled and how you do to add features.
What would you put in “Advanced Topics” ? Even advanced graphics effects should be made simple ! If a code snippet takes more than one-two page, it is (IMHO) bad and it needs to be simplified. However, explanations with the snippets can be made longer (2-4 pages) if the subject is big. But for XIN, it’s the “KISS” philosophy (Keep It Simple Stupid)…
What do you think of that ?
agreed.
Xin is ok for me for First edition.
More chapters/screenshots will be added later.
Xin 1st Edition is out ! 8)
Some things have been added since the “draft” (check it out).
Great! But the page numbers are shifted. I’ll fix that the next days.
observation:
. the use of the demo folder code [ new Xith3DDemoFolder() ]assumes a sub directory pattern, texture etc. this should be spelled out in the tutorial so a new user understands his image data etc needs to be in a specific subdirectory
No. The Xith3DDemoFolder class has nothing to do with the XIN book. The info, you’re talking about needs to be noted in Xith3DDemoFolder’s JavaDoc. And I’ll add it there. But this class is never used in XIN and is only a helper for the org.xith3d.test classes and is not meant to be used for other projects.
Marvin
Though we’d have to :
- Ensure that all can be loaded properly both in filesystems and jars
- Talk of how to do that in XIN
Yes. Agreed.
Do you consider the TextureLoader framework as stable for 1.0 or will it be changed till then?
I was a little confused by the TextureLoader, ImageComponentLoader, TextureStreamLoader and TextureStreamLocator interfaces. I think they could be better seperated by renaming them:
TextureLoader -> ResourceLoader
Since I think it could be usefull to extend the TextureLoader singleton to locate and load all resources needed by Xith (sounds, models etv.)
TextureStreamLocator -> ResourceLocator
Which would be an obvious change, if the TextureLoader is renamed
TextureStreamLoader -> TextureFactory
To ensure that XXXLoader is not mistakable for XXXLocator
ImageComponentLoader - ImageComponentFactory
to follow the scheme
Also I would vote for a ClasspathLocator implementation, that takes a ClassLoader instance as contructor parameter. I think it would be very convenient to have the ResourceLoader initialized to ResourceLoader.class.getClassLoader() per default, so you always have access to resources on the classpath where xith.jar is loaded from.
what do you think?
Mathias
I find the names Loader and Locator confusing, too. So I would be happy, if they’d get renamed in some way. I’m not sure, if all these locators and things actually make sense. I guess, it’s not the most efficient way. And the textures must not be loaded from java internal ImageIO into a BufferedImage and then converted into a Texture, but directly load them by faster loaders into a Texture. I would prefer to get the createTexture() methods out of TextureLoader and put them into a new class called TextureCreator or maybe TextureFactory.
But TextureLoader and ModelLoader should stay separated, since they’re too different to unite them in a common loader system.
We don’t have a common Sound loader yet. So it would make sense to write one and put it to com.xith3d.loaders.sound.
Maybe you want to write a wrapper class, that loads resources and makes use of TextureLoader and the model-/scene loaders. I’ve just improved org.xith3d.loaders.base.* to make the classes more general (not committed yet). If all model-/scene loaders would inherit from this loader base, we’d be a big step further.
Marvin
Let’s see what Amos says to this. Is there any background info, where they came from? They seem to be quite new, since the GSG examples don’t uses this scheme.
Hmm, so there should be dedicated Factories for textures, models and sound. I can think of three possible ways to do this:
1. create XXXFactory singletons which can be extended by registering “XXXProducers” (e.g. ModelFactory with a MD3ModelProducer)
At least TextureLoader follows this scheme… seems the most “service oriented” approach, but may be too J2EE style for games
2. create dedicated classes for each resource type which derive a special base class (e.g. MD3Model extends Model) and take the base name as constructor parameter
I have seen several implementations like this and this seems fast and easy
3. create XXXFactories which inherit resource specific base factories (e.g. MD3Factory extends ModelFactory)
The base factories would specify a create method to force the return type (e.g public Model create(String baseName))
I think solution 1 is oversized and 2 looks suspicious to have a catch (multiple inheritance perhaps). I would prefer something like solution 3. Don’t know what you are doing with the new loader base, but it sounds to go into this direction.
At least from the design perspective, they offer a good abstraction of resource loading. I guess with a little caching of valid stream locations they will be efficient enough. I think it is worth it, to have an abstracted access to different resources, but I would vote for the ResourceLoader to be just some sort of repository singleton where to register locators and move the createXXX methods to some other place (s.o.).
I do not neccessarily need a central point of Texture/Model/Sound instanciation, I just like the idea of a central point to find resources, so TextureLoader looked like the right victim ;). Also I think it is substantial to have good support to load from the ClassLoader.
Mathias
The loaders base does exactly what you describe in point (2.). And I definitely prefer this way. It is an advancement and generalization of the old / current org.xith3d.loaders.scene loaders base. This one is fine except that scenebase doesn’t extend any Group type and the getters return arrays, which need to be created especially for the getters. And there’s no difference between a model and a scene, which is a minor issue, but “solved” in my version.
TextureLoader can theoretically load from an InputStream through TextureStreamLocator. But one had to write an implementation for it. Some time ago I wrote one for zip inputstreams, which is very similar. And org.xith3d.loaders.base.Loader has six methods to load. three to load the file as a Model and three to load it as a Scene. One of each three takes an InputStream, which enables you to easily load from classpath. It is up to the loader implementer to corretly implement these methods.
Marvin
btw. I don’t like the naming of Factory or Producer or things like that for Loaders. They don’t produce a model, but load it. As I mentioned above the TextureLoader has methods to create an empty texture, which is of course needed to load one. But these methods don’t belong to the TextureLoader itself as I think, but to a separate class.