JME sets "RootNode" clone as "Spatial" docs say to never use Spatial?

Troubleshooting SDK
1

Hello!

I wasn’t sure where to put this, because I’m not sure if it’s an IDE issue, or a doc/tutorial issue.

I typed “rootNode.clone();”

and the IDE asked if I wanted to give it a return value, which I did, and I got

    Spatial rootNode2 = rootNode.clone();

I then went to check out what the type of “rootNode” is and it’s “Type Node.” I then went to the tutorials to see what the differences specifically are between a “Spacial” and a “Node” are, and found this link, which says

You never create a Spatial with Spatial s = new Spatial();! A Spatial is an abstract concept, like a mammal (there is no actual creature called “mammal” walking around here). You create either a com.jme3.scene.Node or com.jme3.scene.Geometry instance.

http://wiki.jmonkeyengine.org/doku.php/jme3:advanced:spatial

Note the Spatial s = new Spatial(); is “strike-through” but It didn’t copy over, and I don’t know how to do it on this forum :(.

Anyways, I’m not sure what the rules are, so I wanted to bring up this issue just in case the IDE is not supposed to do that, and just want to make sure that we should be using “Node” which I’m going to do anyways.

Thank you for your time.

2

A node is a spatial.

So, that line is like:
Fruit fruit = apple.clone();

…which is totally fine if all you need is a fruit.

And obviously you can see that it’s waaaaaaaaaaaaaaaaaaaaaaaaaaay different than:
Fruit fruit = new Fruit();

…which is likely impossible if Fruit is an abstract class.

So, either I missed the point of the question or there are some basic OOP things you may want to brush up on.

3

Maybe it will be better for you to go and learn some Java concepts and OOP concepts first and only then return to JME.

Regarding your question, it’s absolutely OK to use variable of Spatial type where you don’t need to know if you are working with Geometry or Node. And it’s NOT OK to try to create new instance of Spatial - you have to use it’s subtypes when it comes to real creation of objects.

4

Yeah, sorry, they aren’t exactly the same, I was just making sure that this is okay.

As for concepts and JME, I’ve been working with JME for a couple of years now on and off.

It’s just that I’ve been curious about this issue for a bit, and why we would set it up in this way, so I got confused about it I guess. I’m reading up something now that I found so hopefully that explains it better…

Thanks.

5

It’s not even an issue - your IDE does it’s best to encourage you to use good practice of using most abstract variable type applicable while dealing with subtype instances.

6

I’m not talking about the IDE, I’m talking about the programming concept of this discussion i.e., Spatial = Node.clone().

From this article I’m reading it says that using implementations are better than using the concrete class itself, and we should “implement” and not “extend” a class.

So I guess it’s what pspeed said and it’s if you need to only use the “Fruit,” but if you need other methods, then you would call “Apple.”

The issue I had awhile ago was that I had an object of “Fruit” but wanted to take the data and make an “Apple” out of it, and add more info to the “Apple.”

but you cannot do “Apple = Fruit.clone().” I ended up using BeanUtils.copyProperties(a,b); which worked great!

7

Well, if the Fruit is an Apple then you can do it with a cast. If it’s not an Apple then it doesn’t make sense… as what would you clone from an Orange to turn it into an Apple? clone() creates a copy… and a copy of an Orange is not an Apple no matter how many ways you slice it.

Spatial is an abstract class. It can never exist on its own so it must be really something else. Geometry, Node, etc… Either one of those will have vastly different internal needs than the other.

8

Thanks, it was one class that was a subclass of another, no Orange/Apple instance.

I did try to cast it as well, but got some error, so not too sure, but did forgot about casting when I made my comment (odd since I had just used it too :stuck_out_tongue: ).

Oh wells, BeanUtils works perfectly, especially since I have to add data to the subclass, so I just copied the superclass’s data and added new data.

9

Also the recommendation is, to never create a own subclass from Node or Geometry (or spatial for that matter)

Apart from a few special cases I omit here, it is most often a sign of not properly splitting rendering and game logic.

10

Thanks for the tip EP :slight_smile:

So you just would use the node or geometry itself, as there’s probably no need to extend them, unless you really have to?

I was thinking about this subclassing case earlier (not that I needed it, but was jw).