Does anyone have a hack/workaround which allows me to set the Appearance of an MD2Model (from the Newdawn MD2 loader) after the model has been loaded? It looks like that isn't possible with the stock version of the loader.Also, is it possible to set the Appearance for individual MD2ModelInstances or only for the base model and, if the latter, will it affect all the Instances of that model?

As with most of the loaders the scene tree reported back is that which is found in the model. The best way I've found to change the appearance at runtime is to seach the scene tree finding the nodes you want to change and reset the appearance. Given that the shape of the tree will always be the same this should be pretty simple.

However, since the source is provided (and there arn't going to be any maintainence updates on the MD2 Loader for a while) you could just change the MD2ModelInstance node to have direct accessors on it.

Do you mind if I ask about something else? Now it seems like the surface normals on my model are completely borked. All of them seem to be set to (x=0,y=1,z=0) or something like that, because when the model is facing towards the light, the whole thing lights up, but when it's facing away, the whole thing goes dark. This behaviour occurs when I use the stock model (tris.md2) provided with the loader as well. Do I need to do something to make it recalculate the surface normals every frame, or something else?

Actually, thats really interesting with MD2s.. Quake 2 had a whole set of pregenerated normals and they were just selected from. In Java3D I applied the normal generator - in Xith3D there was no equivilent, but it was planned so I left it in preperation for that.

And modify the loader slightly so that where its setting the normals, instead of just applying (0,1,0) it selects one from this list based on the index it read from the file you should find all is happy.

If you make the mod - it'd be good to submit back it to the toolkit. Not using Xith3D personally at the moment it'd be a bit of an overhead for me to setup CVS access etc.

The best I can do is post the source here if/when I actually manage to make it work... I'll see about that.

Edit: Yes, I can see what needs to be done. A question about best practices, though: since I'm more or less an armchair coder, what's the best way to go about this?

- rebuild the original package, retaining the name org.newdawn.*,- build a new package, with a different name, that depends on the original xith-md2 package (might be messy to do it this way),- build a new package, borrowing from the existing code and giving appropriate credit, and call it something else,- something completely different?

I believe the MD2 loader have migrated into the Xith-Tk repository (William?) and hence the package has probably already changed on the latest version.

If it'd still been under my maintainence, I'd say submit a patch and I'd make the update on the original code. However, since the loader is in Xith-Tk now the right thing to do would be to get access to that CVS and make the changes to the base.

I think the latest build of the xith-tk already contains it. So, if you don't want to work with the cvs simply post what you've changed in the loader (it's probably only in one single file) and then someone with developer-status will commit it.

I believe the cvs for the loader didn't change since then, but you could make sure, by simply downloading the file your changing by going to xith-tk.dev.java.net -> CVS.

By the way, who have the developer access on the Xith3D core ? William put aside, I don't know any...Maybe the Xith3D project should be more open, it would help it to be more active..

We were talking about the xith-tk here - but I haven't got developer acess for the xith-tk either.

But I think Will would approve your request for a developer role, if you would request one.

Edit: croft probably has developer-role (at least for the xith-tk)

I know we were talking about xith-tk. But I'm talking about xith core. I have developer access for Xith-tk, thanks William, but I think there are things that cannot be put in the xith-tk, such as different culling methods (that are currently only implemented by shape3D), or other optimizations.. I'll pay more attention to these techniques in the future, because actually with the pre-version of the game I'm working on, they are really useless. But I think having them for making a game with very large maps (e.g. a FPS or a MMORPG) could be required.I don't need to have a xith core developer status for now, but maybe in the future. If frustum culling and occlusion culling can be implemented as a separate package, then I'll put them in the Gamma project.(@arne : do you still follow the Gamma project ? maybe it seems to you it's dead, but we've changed the repository.. we now have a private repository that uses SVN. I'll give you more infos if you're stil interested)

I am pleased to report that the new normal modification actually seems to work.

I'm afraid that my modification does raise the RAM load per model quite a bit (approx. 1 extra byte per vertex per frame, plus extra vector arrays to hold the normal data), and I'll have to go over the code and clean it up before submitting. Also, I didn't do a proper normal-interpolation for the frame interpolation as I couldn't figure a fast way to do it, so I just averaged the normals and threw in a quick and dirty hack to prevent it from crashing out if it encountered a zero normal. In the modifications I have attempted as much as possible to privilege speed over memory usage (memory's cheap).

Sorry - like I said, I'm an armchair coder and hence not that well-versed with the use of CVS, etc. Would it be acceptable to just compress up the changed files (5 changed, 1 completely new) and send them to somebody? If so, who? If not, what's the best format for submitting the changes? Is the output from a diff acceptable, and if so which switches should be used for ease of review?

I'm afraid that my modification does raise the RAM load per model quite a bit (approx. 1 extra byte per vertex per frame, plus extra vector arrays to hold the normal data), and I'll have to go over the code and clean it up before submitting. Also, I didn't do a proper normal-interpolation for the frame interpolation as I couldn't figure a fast way to do it, so I just averaged the normals and threw in a quick and dirty hack to prevent it from crashing out if it encountered a zero normal. In the modifications I have attempted as much as possible to privilege speed over memory usage (memory's cheap).

Why don't you make something like a flag "turn_normals_on" then you would have all advantages with no drawbacks?Because then if it is not set, your code doesn't get executed.

Thanks. Have implemented that, but only for loading the MD2Model directly with load() - in other words the load() methods that return a Scene automatically default to loading the version with normal data. I believe that should - hopefully - be sufficient.

I've zipped up the new files, the original files (.old), and diff output (.diff). (MD2Normals.java doesn't have .old or .diff info 'cause it wasn't in the previous version.) Since I don't have write-access to the TK filesharing page, I've uploaded it here:

You should have dev access to the Xith-TK CVS now, please feel free to commit your changes in (assuming from what I've read that they shouldn't break people's existing code) so others can easily benefit.

because it still wasn't commited, I now looked at the code, checked, if it manages everything fine, also with normals turned off, without changing code. I've found nothing to complain about, so I've committed it for 5parrowhawk. Enjoy the changes

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