How to have different point of views with MultiPassView ?

I have a scene (perspective projection) and a HUD (parallel projection).
WHen the camera is at (0, 0, 5) looking at (0, 0, 0) everything’s fine although I want to move and rotate my camera but when I do so the HUD also rotates !!

Oh, it’s fixed now (fixed is really the word to use here) I just had to do hud.setCameraMode(View.VIEW_FIXED); ^^

Another problem for Qudus : about default images for buttons : It seems that the default texture is loaded but it isn’t displayed properly : I see the dummy texture generated by the texture loader when there has been an error loading an image (2x2 checkerboard)

[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:27768"]
Another problem for Qudus : about default images for buttons : It seems that the default texture is loaded but it isn’t displayed properly : I see the dummy texture generated by the texture loader when there has been an error loading an image (2x2 checkerboard)
[/quote]
Fixed. I added the following code to Button :


private static boolean hasAddedSlash = false;
    
    private static Texture loadTex(String resource, boolean useAlpha) {
    	
    	if(!hasAddedSlash) {
    		for (File f : File.listRoots()) {
    			TextureLoader.getInstance().addTextureStreamLocator(
        				new TextureStreamLocatorFile(f));
			}
    		hasAddedSlash = true;
    	}
    	
        if (!useAlpha) {
            return TextureLoader.getInstance().getTexture(resource, TextureLoader.RGB, true);
        } else {
            return TextureLoader.getInstance().getTexture(resource, TextureLoader.RGBA, true);
        }
    }

Pretty neat, heh ^^

When the TestureLoader does have a problem when roots are not added, so why don’t add these lines to the contructor of TextureLoader?

And btw: I still see the default texture on the Button in HUD3DTest.

Hmm I’m not sure it’s a good idea, but…

Update your CVS maybe it was badly committed. I see your default_button*.png images correctly.

[quote="<MagicSpark.org [ BlueSky ]>,post:3,topic:27768"]


    		for (File f : File.listRoots()) {
    			TextureLoader.getInstance().addTextureStreamLocator(
        				new TextureStreamLocatorFile(f));
			}

[/quote]
There’s a problem (at least) on Windows machines. Yes, I know I shouldn’t use Windows as nobody should do :-[ And I will switch back to Linux during the next times. But I had problems with the ATI driver on Linux. Well, I get a little off topic.

The prpblem I’m talking about is, that the floppy is tried to be added and there’s a message saying “No floppy in it” when the above lines are executed.

There’s a problem (at least) on Windows machines. Yes, I know I shouldn’t use Windows as nobody should do :-[ And I will switch back to Linux during the next times. But I had problems with the ATI driver on Linux. Well, I get a little off topic.

The prpblem I’m talking about is, that the floppy is tried to be added and there’s a message saying “No floppy in it” when the above lines are executed.
[/quote]
Eheheh I forgive you for using Windows :wink: :wink: but heh the workaround is pretty easy.
Add a System.out.println(f.getPath()); so you can identify the paths that get added. Then find out which one is the floppy disk : it should be a: then do a f.getPath.equals(“a:”) and if it’s true then don’t add a TextureStreamLocatorFile on this root.

Simple, isn’t it ?

On Linux it even simpler : there is only one root, “/”.

[quote="<MagicSpark.org [ BlueSky ]>,post:7,topic:27768"]
Add a System.out.println(f.getPath()); so you can identify the paths that get added. Then find out which one is the floppy disk : it should be a: then do a f.getPath.equals(“a:”) and if it’s true then don’t add a TextureStreamLocatorFile on this root.
[/quote]
Well, yes. I’ve already solved this one.

[quote="<MagicSpark.org [ BlueSky ]>,post:7,topic:27768"]
On Linux it even simpler : there is only one root, “/”.
[/quote]
Yes, I know. And everybody should really consider using Linux. Regulary I use only Linux, but Windows for gaming.

The other problem with the default textures is still not solved for me. Maybe there really was a committing problem since the DefaultButtonTextureLoader came as an update this morning but there actually wasn’t any change. Maybe I’ve done the same changes that you did.

I’ve modified TextureLoader to take absolute resource names and load them pypassing the locators. So you won’t need to add root folders. So the problem with the default textures for Buttons is solved.

I further suggest to remove TextureStreamLocatorFile and -URL and make the TextureStreamLocator interface being a class with two constructors. One for File and one for URL. There two classes are that similar, we don’t need two and can merge them into one like I suggested. Waht do you say?

OK.
EDIT : Committed.

Hmm I don’t thinks it’s necessary : It’s more hassle for users to migrate from one version to another and it has no great benefit : and TextureStreamLocator should stay an interface : maybe there are others class that can implement it.

[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:27768"]

OK.
EDIT : Committed.
[/quote]
Thanks. But you actually didn’t commit the TextureLoader class, which is most important. Can you please make up for this?

Thanks. But you actually didn’t commit the TextureLoader class, which is most important. Can you please make up for this?
[/quote]
I thought I did. Please check again, I re/cut/paste/committed it.

[quote="<MagicSpark.org [ BlueSky ]>,post:12,topic:27768"]

Yes, now it arrived. Thanks.
[/quote]

[/quote]

Why did you add this absolute file handling inside the getTexture() method - and not add a TextureStreamLocator that is absolute path aware ?

That’s the reason why there are so many interfaces

Ciao Matthias Mann

If you already have an absolute filename, you won’t need a locator. We are loading some textures by <.class.getResource("…")> which returns an absolute path. So we had to the root filesystem folder (linux: /; windows: all drives, except removables), which is not good and even not high-performance. So this should be a good solution for this case.

But this pushes me into an idea:

If we added a new getTexture method to the TextureLoader which takes a File instance, we wouldn’t need a locator for this method and it would be a little faster.

I’ve coded my last thoughts. Can you please (again) commit it to the core?

You should remove the folloowing from getTexture() as it is already in the constructor. If someone removed all TextureStreamLocators then it’s his own fault:

            if (textureStreamLocators.isEmpty()) {
                // Added for noobs
                addTextureStreamLocator(new TextureStreamLocatorFile(new File(".")));
            }

also this:

        if ((tex == null) && ((name.charAt(0) == '/') || (name.charAt(1) == ':'))) {
            // locate the texture directly through its filename
            tex = getTexture(new File(name), format, mipmap);
        }

is bad, because getTexture(File …) addes the texture to the cache.

The cleanest solution would be to just create a TextureStreamLocatorAbsolute() which contains the above code and add this first (in the constructor) - this will result in much cleaner code without code duplication.

Ciao Matthias Mann

Qudus, would you provide me code according to Matthias advices ?

[quote="<MagicSpark.org [ BlueSky ]>,post:19,topic:27768"]
Qudus, would you provide me code according to Matthias advices ?
[/quote]
I will do it in half time break of the game.