Models

umm, well, i supposed it would be nice for us to provide the exporters too.



as for the XML file, here it is:



<player name="John" desciprtion="Cool Guy, dislikes anger, likes Yoga">
   <properties>
      <health value="100" />
      <strength value="50" />
      <agility value="10" />
   </properties>
   <moves>
      <move id="kick" damage="5" constrain="-1" key="d" src="john/kick" count="3" />
      <move id="punch" damage="2" constrain="-1" key="f" src="john/punch" count="3" />
      <move id="superKick" damage="25" constrain="2" key="e" src="john/superKick" count="5" />
      <move id="superPunch" damage="20" constrain="1"  key="f" src="john/superPunch" count="5" />
      <move id="walkLeft" damage="0" constrain="-1" key="LEFT" src="john/walkLeft" count="5" />
      <move id="walkRight" damage="0" constrain="-1" key="RIGHT" src="john/walkRight" count="5" />
      <move id="jump" damage="0" constrain="-1" key="UP" src="john/jump" count="5" />
      <move id="crawl" damage="0" constrain="-1" key="DOWN" src="john/crawl" count="3" />
   </moves>
</player>



As you can see, some attributes are not needed. Health, agility...etc

I know doesn't look much, but it could be a start :D

Hey DP,



Your suggestions are appreciated, however my concern would be that any format originally written for a 2d project turns into a big kludge (mess) when you try to port it to a 3d model. Believe me, I’ve tried it.



Your comment on using effects is more to the topic. I imagine our particle systems would be just another “xml-izeable” part of jme and could handle that in the models.

Howdy,



I’ve come across a series of articles that discuss validating XML data with Java using an XML Schema. I just finished reading them and I think they’re pretty good. We need to do XML Schema driven validation here at work so I think we’ll probably be taking a similar approach to the one in this series.



http://www.javaworld.com/javaworld/jw-09-2000/jw-0908-validation.html

http://www.javaworld.com/javaworld/jw-10-2000/jw-1013-validation2.html

http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-validation3.html

http://www.javaworld.com/javaworld/jw-12-2000/jw-1208-validation4.html





There’s also an XML parser that we use here at work that we might want to consider using with jME because it’s supposed to the fastest. It’s definitely faster than parsing XML into a DOM and then accessing the DOM tree to get at it.



http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/index.html



Gregg

Thank you very much for the input, and keep checking in as we define our custom model format.



I’ve read your post a couple times now and find it to be very helpful. The bone weights are particularly interesting.



The exporters will initially take an already created format (3DS for example) and translate it into the new jME format. Possibly, in the future we can just write plug-ins for various modeling tools. But that will be a ways off.



Very good artwork by the way, and I’d love to see your interpretation of the jME logo.

Sorry, my login went away on while I was entering the previous message.



Gregg

Howdy,



I want to add some more to my previous message…



It also occurs to me that if we handle loading a scene graph as I mentioned before, with the XML element acutally having an attribute that indicates it’s implementation class, we will also need to allow nodes to have the ability to render themselves.



If the jME core has to depend on classes external to the core to load node types that are unknown to the core, the core will also have to depend on the external classes to render node types that are unknown.



From a game/application developers perspective, I would like to be able to handle node types, that are unique to my app, with the jME scene graph, without needing to modify the jME core.



I would like for us to consider providing a way for a Spaital object to, not only persist itself, but also render itself. By doing this we can allow games to add their own unique objects to the scene graph for rendering and persisting with having to make changes to the jME core.



I’ve started down the road of decoupling platform specific rendering from the jME core for Widgets with the WidgetRenderer interface. Every Widget has an instance of a WidgetRenderer implementation to handle drawing the Widget.



I think the pattern I’m using to render Widgets can be used (at least as a starting point) to allow any Spatial object to be able to render itself and still be able to take advantage of code reuse.



I can go into more detail about the WidgetRenderer interface and how I implemented Widget rendering in another thread.



Any opinions?



Thanks,

Gregg

Hey Greg,





Good points. I guess we’ll need to hear from Mojo about the render part. I think it’s a good idea though. For the XML though, having classes that can read and write themselves to XML is something I do everyday in my “real job” and you can make it pretty streamlined without using Castor or any of the other packages out there (although, it requires some work on our part of course.)



Anyhow, nothing new from me on this, just some ramblings. :slight_smile:

I agree, the more I think about it the less I want to use Castor.



Because we have Java code that reads and writes the XML, the validation of the XML is implied, if the XML has something in it the Java code doesn’t recognize (isn’t valid) then the Java code can throw an exception and the app can deal with it.



I think it’s still a good idea to have a schema for external validation of the XML. It also seems like it would be a good way to document the structure.



Gregg

Hi Mark,



Welcome back, I hope you had a good vacation.



For rendering Widgets, I ended up creating the WidgetRenderer interface. Each Widget owns an instance of a WidgetRenderer. The Widget makes a call to a factory class that takes the Widget class as a parameter and returns an instance of a WidgetRenderer that knows how to render the Widget.



This is sort of a compromise that allows the Widget logic to be in a common reusable class while the Widget drawing code is in the WidgetRenderer implementation. The factory class is aware of the JNI platform and creates the appropriate instance of WidgetRenderer.



This still means that there will be a set of platform specific WidgetRenderer implementations, but it keeps me from having to add a draw method to the Renderer interface every time I create a new type of Widget. I’m also finding that a lot of the WidgetRenderer drawing code is reusable so the proliferation of WidgetRenderer implementations isn’t too bad.



Widgets and the code that renders them end up being loosely coupled and the Renderer interface only has to know about the WidgetRenderer interface.



My thought is we might be able to create a SpatialRenderer interface and do something similar to how the WidgetRenderer interface is used. In fact WidgetRenderer could be a SpatialRenderer. Just a thought. :slight_smile:



Also, do you have any suggestions on a way an application might be able to add unique Spatial objects to the scene graph without changing the Renderer interface?



Thanks,

Gregg

Well, I think the major difference between the widget renderer and the scene renderer is there aren’t really any different types to renderer for a scene. Everything you’d use is a TriMesh. Although I support multiple types, lines, points, etc, TriMesh is the only thing that is rendered. So, there really is only a single render method and no other ones should need to be made. This includes: Models, shapes, terrain, indoor levels, etc. So, when someone creates a new object extending TriMesh, it will be rendered the same as pre-existing ones.

  1. does milkshape support facial animations

    and 2. It be possible to include support for facial animation, morph targeting in the custom model format



    btw downloaded milkshape to try it out, tried it and still think max is a hell of alot easier to use, even a real dumb-ass "me" can learn quick and do fantastic stuff with it "images to come soon"

Has anyone looked at X3D as a possible format for persisting a jME scene graph?



http://www.web3d.org/index.html



I don’t know anything about but it looks interesting.



Gregg

Hello



As directions seem to go towards .3ds lately …

(see thread “blender support” in features)



are there any legal issues with fileformats like .3ds ?

(remembering the mp3 discussion)

i quick-searched the web but couldn’t find some official statement nor specs for it so it’s not clear for me if it’s allowed to use it without any form of licencing.



Martin

I’ll ask around and see if I can find out.

Hi



found this on the LWJGL - Lists

might be worth a glimpse:

http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1082385326



Martin

it wouldn’t have multitexture support. I really need that, I’m already engaged in some serious poly crouching where the models are concerned

and did as much as possible procedurals small. whatever is decided I can some major thinking for me in the future

Wow I totally missed this entire thread :slight_smile: The loader I’ve written (inside CVS) uses SAX to read the XML (doesn’t get much faster than that). It uses its own class to write a node to XML. Any Spatial can (theoreticly) be saved and loaded at any time. It saves and loads streams, so compresion can be used. It supports ‘custom’ class loading (IE a programmer can save/load a custom class without having to rewrite the XML loading code). It supports keyframe and joint animations. It supports textues and material states (The other states are pretty trivial to add). It’s self validating. It supports a few controllers but more can be added pretty easily as well. The framework is all there. Exporter utilities are written that can change .ms3d and .md2 to XML format already.



I actually looked at X3D and while its advantages were tempting, mojo convenced me that it would be better for jME to write a load/save format that took advantage of jME’s design. The current loader’s framework centers around Spatial, Controller, and RenderState. Their parent/child relationship is taken advantage of in the format so that it allows for a very intuitive look at how XML files are saved and loaded.



The ability to write converters for ase and 3ds are next on the list. Hopefully they won’t be too hard. Feel free to take a look at the CVS and let me know where the XML package could improve

if your worried about space, dont bother with the xml format, export to md2 instead.



I have just converted my md2 player model (256KB) to the XML format, that gave me a 3.8MB file, after jaring, its down to 1.4 MB, 1.4MB is the entire size of my game!



Cep21, i think this is a big hurdle to overcome, do you have any ideas on how I can decrease the xml size?



Also, how would I be able to select animations, so far, the KeyFrameController can only set keyframes and play through them, how can I select which key frame I want to play? sorta like Md2KeyFrameSelector.setAnimation(int animation)?



DP


when you say converted to xml what do mean. after the conversion can the original model discarded


Well I wouldn't discard it persay. You may want to change the model. But the model wouldn't be shipped with your game. You'ld ship its XML equivalent.

Also, how would I be able to select animations,


Controller.setMintime and Controller.setMaxtmie both set the minimum time and max time for a model. With md2 I assumed the first frame would be time 0 and the last frame would be time=nNumFrames-1. So if you want to play frames 6 (time=5 {0 indexing and all} ) to frames 10 (time=9) then just set min time to 5 and max time to 9.

Cep21, i think this is a big hurdle to overcome, do you have any ideas on how I can decrease the xml size?


As far as XML size, that is a toughy. I presented that hurdle to mojo at the begining, I don't think there is any real answer. No matter what I do, a human readable file (IE XML) representing something will allways be larger than a binary file representing something. Humans are just more inefficient than computers with language. I could write a compressor that would compress jME's XML files in some kind of jME specific way (then you can pass that thru a jar). It may help for distribution without taking the "Human Readable" out of it (just uncompress). Human readable jME format is important though (for ease of use).

I'm open to suggestions on what to do. I'll be pondering it in my free time.

You could make a binary format that is 1 to 1 with the xml. In a system like this a compiler would compile the xml for distribution but you would be able to load xml directly so you could debug it. (Like Microsoft’s .x file) (Another advantage of this system would be the ability to encrypt the binary files). When I wrote the file format for my game I made a layer in-between the game and the file so if I wanted compression all I had to do was change the layer)