Shouldn’t SpatialTransformer, extending Controller, support all of it’s implied functionality, too? MaxTime, MinTime, and RepeatType don’t seem to have any impact on the SpatialTransformer’s output. I’ve read in a post from Cep somewhere around that SpatialTransformer is’nt supposed to do anything more than standard RT_CYCLE behavior, with default MinTime and MaxTime, apparently. Fine, but maybe it shouldn’t extend Controller, then, or even better, it could implement the missing functionality nevertheless. I am currently experimenting with modifying SpatialTransformer, so I could contribute the missing functionality, if somebody is interested.
It should support all of that, I agree. It was originally written to animate the 3ds file format correctly. Animating 3ds files doens’t require any of that, so that’s why they aren’t currently supported. Any changes to it would have to make sure 3ds files still animate the right way. It extends Controller because that’s how all things in jME are animated.
If you want to update the Controller to support those features, let me know if you need any help understanding the current code.
Great, thank you!
I think the relevant stuff is done in SpatialTransformer.setBeginAndEnd(). Looks like I would have to set beginPointTime and endPointTime properly, along with negating the speed when in RT_WRAP mode, and that would be pretty much it. I’ll try that and ask you for help if I stumble upon something I don’t understand.
I think I am done adding support for MaxTime, MinTime, and RepeatType. I haven’t tested the 3ds thing, though ,because I don’t have any animated 3ds files, and if I had, I would’nt know if they made good test cases… Cep, maybe you can do the 3ds testing? That is, if anybody’s interested in having my code in cvs…
The new SpatialTransformer class is here:
http://wwwhomes.uni-bielefeld.de/krabien/jmestuff/SpatialTransformer.java
My code replaces the old setBeginAndEnd method completely, as well as adding a little auxiliary method findIndicesBeforeAfter.
Also, the setMinTime and setMaxTime methods are overridden to always have their times in the range of the SpatialController’s keyframes. If this is not good, please let me know, I can find another solution. Javadoc is included.
p.s. the @author tag in the new method’s javadoc can be removed, of course, I just thought it might be handy for future reference…
Give me about a week and a half too look at it. It’s finals week coming up so I’m cramming in a lot of project right now.
Nevermind, I just noticed it’s actually not that finished… one more thing I didn’t test is using the SpatialTransformer “by hand”. Loading from xml works just fine, but programmatically creating a SpatialTransformer and setting it’s keyframes results in a SpatialTransformer doing nothing at all. I’ll have to check that. Good luck for your finals, Cep!
EDIT: problem fixed and file updated
[bump] any news on this, cep? [/bump]
EDIT: Do you think it would be possible to change the private fields and methods to protected? That would be vital for extending SpatialTransformer, maybe for adding support for keyframed messages (see http://www.jmonkeyengine.com/jmeforum/viewtopic.php?t=1714), or other keyframe- related stuff.
I’m sorry I took this long to get back to you on this. I tested the code and it seems to work perfectly on all the test suits currently implemented, as well as any small changes I could think of to throw at it.
As far as changing private to protected, I’m not so sure. I’ld like to use protected only when absolutly needed. Maybe a more stable way would be to have a public “hook” method that users can override with their own code, which is initially blank inside the controller. The hook would be called inside the update. Or maybe adding hooks could be solved another way Controllers are removed from Spatials and put into their own manager.
I recomend it be formatted and commited.
I believe the next step is, unless anyone has objections, for mojo to format the code and commit it.
Cep, I understand your objections on making members of certain classes protected. In the case of SpatialTransformer, however, I don’t agree. With jME being an API, and SpatialTransformer a core part of it, shouldn’t users be able to extend subclasses with new functionality? This is not possible the way it is right now, because some key fields like curTime and beginPointTime are private. I don’t think making them protected will yield that many problems, because someone subclassing SpatialTransformer should hopefully have at least a faint idea of how it is working, and what (not) to do with it. Preferably, I’d like to see all the fields and members that are private now become protected, because that would allow a cool trick for ‘converting’ xml loaded SpatialTransformers to some custom subclass, by cloning them. A subclass could simply initialize all it’s fields with the xml loaded SpatialTransformer’s one’s, if that makes sense…
I guess I could go either way on protected. If someone else has a big reason to think it’s important, I can’t think of any big reason to think it’s just as important to keep them private. So I’m fine with that too.
Is there any chance this is going to be committed?
Fix committed by mojomonk - thanks!