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 3
  ignore  |  Print  
  Adding the newdawn loaders to the distribution  (Read 9126 times)
0 Members and 1 Guest are viewing this topic.
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Posted 2005-06-13 05:17:55 »

I notice on the new dawn xith3d loaders page, the line "The following loaders are supplied externally to Xith3D but hopefully will migrate into the code base eventually."  I agree, I think this would be a really good idea.

Kev and Jeremy, do you mind if I do put them in CVS?  I would make them part of the toolkit which is distributed along side Xith3D.

Cheers,

Will.

Edit: added URL

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #1 - Posted 2005-06-13 17:23:19 »

And why don't put one of the 3DS loader, and the MD2 loader, too ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #2 - Posted 2005-06-14 08:49:49 »

yes that was the plan, sorry I meant to link to the page I was talking about.

Will.

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

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2005-06-14 09:20:33 »

I don't see any problem with this. Probably be nice to change the packaging (I assume that'd happen?). Its worth noting that the 3DS loader isn't fantastic for animation (see sooooo many posts on the topic :/).

I think Jez made the AC3D loader available in Xith aswell..

Kev

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #4 - Posted 2005-06-14 09:52:16 »

cool, yes I would repackage it.

Is MD2 your recommended animation format?

Will.

Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2005-06-14 11:53:50 »

MD2 is simple and works well if you can get your models into that format. For keyframe its really just fine.

What we could really do with is a full featured milkshape loader. I know its heresy, but supporting the .jme format in a loader might save alot of hassle and leverage the work being done over there.

Kev

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #6 - Posted 2005-06-14 15:59:54 »

I'm actually doing a Cal3D port for Java using Xith3D for the Gamma project.
Maybe It can be included in Xith3D and then reutilised in gamma.
Cal3D support really cool features : skeletal animation, animation blending...
More informations on http://cal3d.sourceforge.net/
Note : I'm not sure I can finish the port ( say, if it is possible, or realisable ), but it is a project.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline dsellars

Junior Member




Need to write more games


« Reply #7 - Posted 2005-06-14 17:15:32 »

Sorry slightly OT.

I believe that some work has neen done on Cal3d at this site

http://www.shortfuze.co.uk/shortfuze/template/Index.vm

It might be worth checking out.

Dan.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #8 - Posted 2005-06-15 13:25:21 »

Yes I know.
A Java port has been made for Fuze3D, but it was the 0.8 version.
I'm doing a port of the 0.10. However, I could ask the guys from ShortFuze to send me their code but...
I don't know if it would save time.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline dsellars

Junior Member




Need to write more games


« Reply #9 - Posted 2005-06-15 13:38:37 »

ah is there a big difference then?

One thing that always put me off looking into Cal3d was not being able to find any models for it.  It seems like a great idea but a bit useless with out models.  I know there are exporters for stuff like blender but my modeling skills are pretty useless really.

Oh well sorry it's off topic.

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

Senior Member




Everything's possible, but not everything's fun...


« Reply #10 - Posted 2005-06-16 21:25:58 »

ah is there a big difference then?

One thing that always put me off looking into Cal3d was not being able to find any models for it.  It seems like a great idea but a bit useless with out models.  I know there are exporters for stuff like blender but my modeling skills are pretty useless really.

Oh well sorry it's off topic.

Dan.
Yes, there is really a big difference.
The biggest ( to me ) is that the Blender exporter work only from 0.9 version...  Grin
And when another version of Cal3D is released, there is a good reason.
You can convert any model into Cal3D, just open it in 3DS max, or in Blender and export it..
You don't need to have modeling skills...

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline croft

Junior Member




Java, Java, Java


« Reply #11 - Posted 2005-08-02 21:41:03 »

I don't see any problem with this. Probably be nice to change the packaging (I assume that'd happen?). Its worth noting that the 3DS loader isn't fantastic for animation (see sooooo many posts on the topic :/).

I think Jez made the AC3D loader available in Xith aswell..

The New Dawn Software loaders pull the texture files from the classpath.  I tried to trick the loaders into pulling them from an arbitrary directory selected by the user by extending the classpath via URLClassLoader and some reflection by I was not able to get it to work.

To take the next steps with Whoola 3D Browser and Whoola COLLADA Converter, I need to be able to modify the New Dawn Software loaders so that they load from some arbitrary location supplied by the application such as a URL or a user directory.  It would be nice if the location was provided by an object implementing an interface so that the application could use a cache.  Here is an example interface:
http://cvs.sourceforge.net/viewcvs.py/croftsoft/croftsoft/src/com/croftsoft/core/util/cache/ContentAccessor.java?rev=1.3&view=auto

Once this change is made, Whoola 3D Browser will be able to load file formats other than COLLADA and Whoola COLLADA Converter will be able to convert files from user directories using the New Dawn Software loaders.  This is sort of a critical path for me so I would be happy to dedicate the time to move the New Dawn Software loaders into Xith if New Dawn and Xith grant permission.  Once granted, I could do it within a week.  I would then make the changes I need.

Please let me know if this is OK or if New Dawn Software wants to do this.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #12 - Posted 2005-08-02 22:56:34 »

Which of the loaders are you refering to?

The AC3D Loader at least accepts a texture path, which is relative to the model path.

Endolf

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2005-08-03 11:48:55 »

I don't see any problem with this. Probably be nice to change the packaging (I assume that'd happen?). Its worth noting that the 3DS loader isn't fantastic for animation (see sooooo many posts on the topic :/).

I think Jez made the AC3D loader available in Xith aswell..

The New Dawn Software loaders pull the texture files from the classpath.  I tried to trick the loaders into pulling them from an arbitrary directory selected by the user by extending the classpath via URLClassLoader and some reflection by I was not able to get it to work.

We have some code to sort-of do this we wrote for Survivor, which I've been meaning to put online for about 12 months Sad - it's designed so that you can drop files into a directory and they automatically override whatever is in your JAR files. IIRC it only works on directories that are relative to the classpath - but also IIRC this is the only thing that is physically possible in Sun's java (at lesat, it was back in java 1.2; things have changed in the ClassLoader impl since then, so maybe not any more). If you are having problems, it's almost certainly because some code somewhere is using instanceof - which *by definition* (although not really documented last time I looked, again could be updated by now) always returns false on things loaded by different classloaders - even if it's the same file.

You might also want to take a look at the source for the "arbitrary find and load any class anywhere on the classpath" class:

http://javagamesfactory.org/views/view-sourcesnippet?id=1

It only searches the classpath, but finds all: files, JARs, ZIPs, and extracts the class names that are hiding within them and instantiates those classes (if requested).

malloc will be first against the wall when the revolution comes...
Offline croft

Junior Member




Java, Java, Java


« Reply #14 - Posted 2005-08-03 20:29:59 »

Which of the loaders are you refering to?

The AC3D Loader at least accepts a texture path, which is relative to the model path.

I would like to start with the OBJ and MD2 loaders since I have models in those formats.

Here is a revision to my proposed interface:

1  
2  
3  
4  
public interface  InputStreamOpener
{
public InputStream  open ( String  name ) throws IOException;
}


The "name" argument would be some identifier or path to retrieve the InputStream relative to a baseURL, classpath root, or user-selected directory.  The other possibility is that it would be a cache identifier.  Ideally, the loader would retrieve the InputStream using a filename without knowing whether the file was cached, pulled off of a website, on the classpath, or generated dynamically.

It would be almost exactly like com.xith3d.loaders.texture.TextureStreamLocator but only more generic.  Is TextureStreamLocator something that was introduced to with TextureLoader2?  If so, would it be sufficient to simply update the loaders to use TextureLoader2?

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline croft

Junior Member




Java, Java, Java


« Reply #15 - Posted 2005-08-03 20:35:41 »

It only searches the classpath, but finds all: files, JARs, ZIPs, and extracts the class names that are hiding within them and instantiates those classes (if requested).

Unfortunately I need to be able to pull the files from an arbitrary URL in the case of the Whoola 3D Browser or a user-selected directory in the case of Whoola COLLADA Converter.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #16 - Posted 2005-08-06 05:01:25 »

I am in the process of moving the 3DS, OBJ and MD2 Newdawn loaders in to the xith-tk shared CVS as planned.

I agree it would be nice to have some sort of universal resource loading method amongst all the loaders (at least the ones in the toolkit).  Perhaps this functionality can be abstracted out, with the default being to load from the classpath.

Once the code is in the CVS, such changes will be possible.  According to the governance of the project though, consent is desired from the original author(s) before changes are made.

Will.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #17 - Posted 2005-08-06 15:23:32 »

xith-tk

What happened to the plans for making this:
 - more obviously named
 - more obvious and easy-to-find and easy-to-load a resource for devs
 - modularised

?

Apologies if some of the above are incorrect, I can only vaguely recall what was suggested Smiley

malloc will be first against the wall when the revolution comes...
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #18 - Posted 2005-08-07 04:04:27 »

What happened is that we now include the tools with the main distribution.  Go download a copy of Xith3D, and it should be there.

Modularised?  Each tool has it's own package.  Each package has package level documentation stating what it's dependancies are.  For example, if you write a tool A, you specify what other tools it depends on.  This way, anyone should be able to cut out unneeded classes without trial and error.  Most tools are self contained, certainly all of the current batch are.

As for information to developers of Xith3D tools, this page exists (accessed from the "Docs" link) to tell them what to do:  http://xith.org/XithToolkitContributions (see also the guidelines).

The current roadmap sees many of Xith3D's non-core packages (e.g. ASE loader, userinterface) moved into the toolkit.  The idea is then to foster better community development of non-core apsects, while keeping the core code under stricter quality control (i.e. developer and community review -- example, see recent texture loader changes).

Regards,

Will.

Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #19 - Posted 2005-08-09 12:47:29 »

As far as I'm concerned, since the newdawn loaders have been released to the Xith codebase proper you can do whatever you like to them.

I'd hope the new versions in XithTk become the reference point rather than the newdawn site and hence the new updates will be available to everyone.

Kev

Offline croft

Junior Member




Java, Java, Java


« Reply #20 - Posted 2005-08-11 20:25:50 »

As far as I'm concerned, since the newdawn loaders have been released to the Xith codebase proper you can do whatever you like to them.

I'd hope the new versions in XithTk become the reference point rather than the newdawn site and hence the new updates will be available to everyone.

May I have permission to update them in the xithtk CVS?  I would do so in gradual, incremental steps with the first objective being to allow loading textures from arbitrary sources.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #21 - Posted 2005-08-11 21:35:12 »

I believe you just join the java.net project and you should have access.

Kev

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #22 - Posted 2005-08-12 04:37:19 »

Go for it!  If you don't have dev access, just apply.

May I ask what is your plan?

The way I see it some abstract texture providor would work well, with people free to code custom ones (for things like loading from a URL).  We could probably build this in to TextureLoader2.

Will.

Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #23 - Posted 2005-08-14 03:06:32 »

The last loader, MD2 has been added.

Thank you once again to Newdawn for these excellent loaders!  The MD2 one is particularly impressive.

Regarding any modifications, it is of course always best to discuss proposed changes in the forum before making them, that way we can all review them and add our suggestions.

Cheers,

Will.

Offline croft

Junior Member




Java, Java, Java


« Reply #24 - Posted 2005-08-16 00:25:33 »

Regarding any modifications, it is of course always best to discuss proposed changes in the forum before making them, that way we can all review them and add our suggestions.

OK, I'll study and propose here before committing.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline croft

Junior Member




Java, Java, Java


« Reply #25 - Posted 2005-08-16 00:57:58 »

May I ask what is your plan?

The way I see it some abstract texture providor would work well, with people free to code custom ones (for things like loading from a URL).  We could probably build this in to TextureLoader2.


OK, here is my plan:

1.  Modify org.xith3d.loaders.obj.OBJLoader in project xith-tk to extend from com.xith3d.loaders.LoaderBase.  Initially I would leave the original method signatures in OBJLoader as they are and just add the new methods from interface Loader.

2.  Replace the use of TextureLoader in the loaders with TextureLoader2 at the same time, if required to get it to work.  Otherwise, do it later.

3.  Post the source code on this forum for comment and corrections.

4.  Commit.

5.  Do the same to the other loaders (MD2, etc.).

6.  Create a super loader which can delegate to the other format-specific loaders depending on file type.

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline kevglass

JGO Kernel


Medals: 122
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #26 - Posted 2005-08-16 17:22:56 »

Step 6 was a problem in Java3D. The super loader interface is great if you're assume that the object you get back from loading is always the same thing, i.e. a BranchGroup. However, alot of the geometry loaded for games isn't static, people like animation, at that point you need some API for controlling the current frame and/or animation weights and positions.

You could introduce some sort of generic animation Controller type as with JME but from experience this suffers from the way to generic for the purpose problem aswell.

Still, the super interface is still worthwhile, just that things underneath have to be exposed aswell. Unless of course you just want to cast the object back to whatever the user is suppose to know it is.</evil>

Kev

Offline croft

Junior Member




Java, Java, Java


« Reply #27 - Posted 2005-08-16 23:36:07 »

Step 6 was a problem in Java3D. The super loader interface is great if you're assume that the object you get back from loading is always the same thing, i.e. a BranchGroup. However, alot of the geometry loaded for games isn't static, people like animation, at that

I've hit a snag.  The first OBJLoader load() method returns BranchGroup but interface Loader expects Scene.  This causes an interface conflict when I extend OBJLoader from LoaderBase.

A quick fix is to change the return value in OBJLoader from BranchGroup to Scene by wrapping a SceneBase around the BranchGroup via SceneBase.setSceneGroup().  This changes the method signature of the load() method, however, which breaks pre-existing code.  Application code would need to change load() to load().getSceneGroup() in order to get the BranchGroup.

I can either change the method signatures or create a new class called OBJLoader2 to do what I want to do.  I prefer the former.  Any objections?

David Wallace Croft / www.CroftSoft.com / (214) 636-3790 m / Advanced Java Game Programming
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #28 - Posted 2005-08-17 07:38:55 »

Before you worry too much about com.xith3d.loaders.Loader et. al. evaluate how useful this interface is to start with.

AFAIK, no loaders, even the ASE loader which is in the core and was originally created by David Yazel, actually use it.

So if you think there are ways to improve the interface we can look at them.

I don't think there is a problem with interface changes at this stage -- nobody is using these loaders at the moment from the org.xith3d package anyway  since they were only just added.  The most important goal for now is having the best design possible Smiley

Cheers,

Will.

Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #29 - Posted 2005-08-17 08:51:44 »


I don't think there is a problem with interface changes at this stage -- nobody is using these loaders at the moment from the org.xith3d package anyway  since they were only just added.  The most important goal for now is having the best design possible Smiley


I do, but a good design is more important and it won't be a big problem to change the code. But I think when we want to improve the design, we'll also have to think about Scene. As an example Scene got a function "getBehaviors()", but in Xith3d we don't use Behavior classes, or does anybody? And Scene hasn't got a function like "playFrame(int n)" which we would need for animations.

:: JOODE :: Xith3d :: OdeJava ::
Pages: [1] 2 3
  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 (25 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 (33 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!