got another problem...I tried to load a simple cube, exported from wings3D or Blender.The loaded cube from the Blender-file is black or white depending on some settings; the wings3D-file is loadable with texture but (that's my problem) I want to change the texture or material of the cube but i can't reach the cube.I load it that way: scene = objL.load("Test.obj");Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");I used to test it but if I try to load the object that way, I got a classCastException... The only thing working is loading the file as scene, but no chance to set material or texture there.Where is the mistake? Wrong export?

I tried to load a simple cube, exported from wings3D or Blender.The loaded cube from the Blender-file is black or white depending on some settings; the wings3D-file is loadable with texture but (that's my problem) I want to change the texture or material of the cube but i can't reach the cube.

Hmm... Sorry. I can't help you with this. But certainly Amos can. I guess he worked quite a lot with the loaders.

I load it that way: scene = objL.load("Test.obj");Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");I used to test it but if I try to load the object that way, I got a classCastException... The only thing working is loading the file as scene, ...

The loader base currently used by ObjLoader returns an instance of "Scene", which is an interface and therefore doesn't extend BranchGroup ao another GroupNode extension. Even the concrete class used internally inside the loaders doesn't extend GroupNode. You'll have to use xy.getSceneGroup() as the Node to add to the scenegraph.This is different in the new loader base, where any scene or model extends BranchGroup resp. Group. So they can directly be attached to the scenegraph. They're TransformNode as well and can therefore be directly transformed (like scaled), which was also not possible in the old system.

..., but no chance to set material or texture there.Where is the mistake? Wrong export?

You can always traverse the model ( getSceneGroup() ) and find any Shape3D and apply a Materail to it. But I guess it is better to wait for the failure to be fixed inside the loader. Maybe you could yourself dig into the code and try to find the solution.

I load it that way: scene = objL.load("Test.obj");Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");I used to test it but if I try to load the object that way, I got a classCastException... The only thing working is loading the file as scene, ...

The loader base currently used by ObjLoader returns an instance of "Scene", which is an interface and therefore doesn't extend BranchGroup ao another GroupNode extension. Even the concrete class used internally inside the loaders doesn't extend GroupNode. You'll have to use xy.getSceneGroup() as the Node to add to the scenegraph.This is different in the new loader base, where any scene or model extends BranchGroup resp. Group. So they can directly be attached to the scenegraph. They're TransformNode as well and can therefore be directly transformed (like scaled), which was also not possible in the old system.

Yes I know!That's why I dont understand that someone works with loading as BranchGroup... Was it possible in an older version?

..., but no chance to set material or texture there.Where is the mistake? Wrong export?

You can always traverse the model ( getSceneGroup() ) and find any Shape3D and apply a Materail to it. But I guess it is better to wait for the failure to be fixed inside the loader. Maybe you could yourself dig into the code and try to find the solution.

When I said "traverse" I wasn't talking about myNode.traverse(). I guess, you don't want to apply the same appearance or material to all Shape3Ds in the model. So you'll have to traverse "manually". This means, that you'll have to know the exact "path" in the model's graph and apply the specific materials to the shapes.If you do want to apply the same material (or something like that) to all the shapes, then you should use model.getSceneGroup().traverse().

There're two overloaded versions of the traverse() method. One taking a TraversalCallback instance and one taking a DetailedTraversalCallback instance. The letter one is just for really complicated traversals, where you whould have to cast again and again.In your case have a look at org.xith3d.scenegraph.traversal.impl.MaterialTraversal and take it as an example for your traversal implementation or just use one of the implementations from that package.

The only documentation existing for that is the JavaDoc. But I guess it is sufficient. Please tell me if it is not.

got another problem...I tried to load a simple cube, exported from wings3D or Blender.The loaded cube from the Blender-file is black or white depending on some settings; the wings3D-file is loadable with texture but (that's my problem) I want to change the texture or material of the cube but i can't reach the cube.I load it that way: scene = objL.load("Test.obj");Some posted codes load it like BranchGroup xy = null; -> null = new OBJLOader().load("xy");I used to test it but if I try to load the object that way, I got a classCastException... The only thing working is loading the file as scene, but no chance to set material or texture there.Where is the mistake? Wrong export?

So there is nothing else but the cube. Scene.getSceneGroup().numChildren() returns a 1. Traversing the scene should be done with getChild(0) ... correct? But I can't cast it as shape3D or something else. And I am not able to set texture, material or something in that state.What is the alternative? I need a good loader where I can change the appearance from the loaded object. And I need a free programm that allows me to export in this file. (e.g. Blender or wings3D...).

I haven't tested it so it maybe doesn't work i'll make an example of that.

Hope it's fine for you.

Cool idea to add these methods. But isn't the toolkit a better place for them? I think, adding them to the org.xith3d.scenegraph.traversal.impl package in the toolkit and org.xith3d.scenegraph.traversal.impl.SGUtils was a better way, since all other traversal implementations resist there. Do you agree?

Cool idea to add these methods. But isn't the toolkit a better place for them? I think, adding them to the org.xith3d.scenegraph.traversal.impl package in the toolkit and org.xith3d.scenegraph.traversal.impl.SGUtils was a better way, since all other traversal implementations resist there. Do you agree?

I don't know if every cool thing must absolutely be excluded from the core. For me here are the place they're the more convenient.

Just to be able tp doOBJLoader.load("yourscene.obj").getSceneGroup().get("xy").toShape().getAppearanceLazy().setTexture(TextureLoader.getInstance().getTexture("mytexture.jpg"));is just cool.. (note : the toShape() and getAppearanceLazy() aren't implemented)

Just to be able tp doOBJLoader.load("yourscene.obj").getSceneGroup().get("xy").toShape().getAppearanceLazy().setTexture(TextureLoader.getInstance().getTexture("mytexture.jpg"));is just cool.. (note : the toShape() and getAppearanceLazy() aren't implemented)

There are. They're called loadModel() and loadScene(). The only difference is that the returned type is OBJModel resp. OBJScene, which extend org.xith3d.loaders.models.base.Model resp. org.xith3d.loaders.models.base.Scene. org.xith3d.loaders.models.base.Model extends TransformGroup and org.xith3d.loaders.models.base.Scene extends BranchGroup.

But they're not static and have never been for OBJLoader. And I think creating an instance for the loader is no problem, since GC is only created at load time. And it is necessary for inheritance of org.xith3d.loaders.models.base.Loader. Maybe we could add a getInstance() method to all loaders to make them usable as singletons.

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin

Well that's no problem for me but regular users may not be happy with such a not-so-important function renaming...

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin

Well that's no problem for me but regular users may not be happy with such a not-so-important function renaming...

Hmm... They don't need to rename it on user side. It's just deprecated. And I think having a streamlined API at the end is worth a lot, isn't it.

Well so why not, why not add a developer guideline for that kind of things also ?

Could you maybe stop that? I'm so happy, we finished the lazy discussion about code guidelines and found a quite fair consense. So we don't need to proceed it on other threads and stay friends. OK?

Wait that wasn't meant to be sarcastic.

Not everyone knows getter methods for booleans are of isXXX() form. Not everyone is supposed to know we want to use instance() named methods instead of getInstance() for singleton classes.. I meant we could mention that in the "Developers Infos" (and I really think it's a good idea).

Woah calm down guy.

EDIT : I think, we're all getting a bit nervous these times.. sorry man if you felt offended

I tend to find getInstance() method long but for the sake of design maybe naming them simply "get()" wouldn't be appropriate...

I agree, that it is too long. I just wanted to match the naming, you (or Matthias Mann?) selected for TextureLoader. Quite often I've seen a method called instance() (without the get prefix) for singleton classes. Maybe this would fit better. But then we should change that for TextureLoader, too (and make the old one deprecated).

How do you like that?

Marvin

Hi, I'm finally back at JGO (logon issues)

I choose the name getInstance() because sometimes I also have createXYZ methods - get signals a invariant behavior between calls. Also this getInstance() method is static and thus does not conflict with a bean property.

Long method names serve also as a documentation - I prefer them over too short and meaningless names.

But I don't want to start/continue any quideline issue - this post is just to explain the code (method names) that I had created.

I choose the name getInstance() because sometimes I also have createXYZ methods - get signals a invariant behavior between calls. Also this getInstance() method is static and thus does not conflict with a bean property.

But I think nevertheless that decisions like that should be written somewhere... if I know a bit as programmers work, if there's a doc maybe they'll read it (partly at least) if there's nothing, they'll do their work, no really matter how..

java.io.FileNotFoundException: Untitled.mtl (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(Unknown Source) at java.io.FileReader.<init>(Unknown Source) at org.xith3d.loaders.models.impl.obj.MaterialLibLoader.<init>(MaterialLibLoader.java:87) at org.xith3d.loaders.models.impl.obj.OBJLoader.load(OBJLoader.java:148) at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:195) at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:202) at org.xith3d.loaders.models.impl.obj.OBJLoader.loadModel(OBJLoader.java:207)

I'm streamlining the model loaders and therefore porting all of them to the new loader base. This is why the previous usage isn't valid anymore. But you can grab the legacy-loaders.jar (mentioned above in this thread) to use the old loaders. But it is advisable to use the new loaders, if your project is work in progress. I guess / hope, it is not too hard to port, is it?

I'll check, if the baseURL of the loader can always be safely retrieved from the given URL in loadModel( URL ). If it is, I'll modiy the loaders to do it. Then you won't need to set the baseURL of the loader and the call will work as you expected.

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