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?
Thanks in advance.
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.
Kev
Thanks. I’ll see about dumping the tree out and fiddling with it. 
Edit: Yes, it seems to work. Thank you!
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.
If you use this class:
http://www.cokeandcode.com/code/src/render/org/newdawn/render/models/md2/MD2Normals.java
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.
Hope that helps,
Kev
Thanks again! I’ll give it a shot, but don’t have CVS myself 
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?
Thanks.
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.
Of course, you can at the end of the day, do as you choose
Kev
yup it’s in the xith-tk.
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…
[quote]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…
[/quote]
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)
Anyone is welcome to become a member of the Xith-tk project, it’s very open.
We only ask that you respect other people’s work and don’t break the standards that are in place.
Read this info: http://xith.org/XithToolkitContributions and the linked governance page (which also explains why the TK project exists and why it is good)
arne, Magic Spark, kevglass, please feel free to apply and I will approve the requests ASAP.
Cheers,
Will.
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)
[/quote]
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)
[quote]we now have a private repository that uses SVN. I’ll give you more infos if you’re stil interested)
[/quote]
give me those infos and I’ll look if I have time (depending on how much has changed since)
I’ll send you by PM.
Sorry, I’m confused.
Re the core, Yuri and I are the two main people with commit access. Most changes that are submitted are committed (e.g. TextureLoader2), however there is a quality process to keep the core clean.
If you would like to make a change to the core, please submit an issue on IssueZilla with either changed files or a diff, the community can review it and I will commit it in.
Cheers,
Will.
Okay, I see.
No problem, then.
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?
Thanks for all the support and help.
Nice work
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.
Arne
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:
Nice work chap!
Kev
Hi,
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.
Thanks,
Will.