So you like Textures eh? Texturing Demo in JOGL.

Hey.
I got the texture code to work in the port of my collisions_demo from java3d to opengl, however the colors seem to be a bit wrong.
Here’s a snap that would help you understand what I’m talking about
http://www.realityflux.com/abba/weird.jpg

original
http://www.realityflux.com/abba/collisions.jpg

I spent a little short of a day doing the port since I’ve never done opengl before (woah some complicated stuff there ???, but I’ll get through it ;D), and I love it to pieces, JOGL that is :).
PS: the jogl port runs about 30-40% faster than java3d :P.

The colours look the same to me on the walls at least. The ground looks to be a different texture all together?

Also, could you not post these big images into the forum, its probably a problem for dial up users and also make the layout go a bit off…

Is the ground the bit that seems to be the problem?

Kev

Nah dude the walls albeit looking similar, you can still notice a tiny difference in between the stones (it looks a bit brownish rather than grey).
The floor is a totally different texture, but take a closer look at the cylinders; I’m positive you’ll see that the difference in between the j3d and jogl rendering is obvious.
Any help on that?
PS; the textures are in jpg format, lemmie go check with png :slight_smile:

Yeah, actually see what you mean with the “logs”. Maybe it something to do with lighting? The way the texture loaded works (as I remember) is to ask java in 2d to convert from whatever image you specify into something Jogl can handle… so I suppose if there is a problem, it might be worth looking at the images created in the conversion routine: convertImageData

I’ve been using GIF and PNG files and haven’t noticed any problems (and I’m working in 2D, so they’d be bleady obvious ;))

Kev

PS. Thanks for changing those images to links, very community spirited of ya. :slight_smile:

Troggan: Your application ran fine for me, i got 2 fps, but what do you expect from a 2mb card…

here is the code for my TextureDemo, it is just a rotating cube with some basic lighting… run "java TextureDemo " + the filename of any texture. You will need the Texture and TextureLoader classes shown earlier, but i didnt use the original package names so you may need to import them…
The frame rate will be displayed in the console, i would like to know what you get… it should pretty much be vsync capped for any decent card.

W00t just as I suspected; saving the images as png instead of jpg solved the problem.
I also noticed a very bizarre thing: check this screenshot out and tell me if it’s just my eyes going nuts at 3.46 in the morning or the frame rate almost doubled? :o
http://www.realityflux.com/abba/w00t.jpg
It’s at least twice as fast as what j3d was giving me framerate wise
/me hugs jogl ;D

my application would work only like 1/3 of the time i ran it, but now i removed that texture.bind(gl) statement, and its working… why is the texture being displayed if i dont bind it?

those are some great results… where can i find the original application? did you post your code, i would like to try to run it…

wait, damn. its still not working 100%, its soo wierd, its just like randomly choosing when to work. and it seems that when it doesnt work once it will stop working until i like recompile or restart the terminal. this is sooooo annoying

Could it be a driver problem? What GFX card are you running on and have you got the latest/best driver?

Kev

i tried to run it and got this:
net.java.games.jogl.GLException: Surface already unlocked
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.unlockSurface(WindowsOnscreenGLContext.java:189)
at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.free(WindowsOnscreenGLContext.java:131)
at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:197)
at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:179)
at net.java.games.jogl.GLCanvas.display(GLCanvas.java:84)
at net.java.games.jogl.Animator$1.run(Animator.java:104)
at java.lang.Thread.run(Thread.java:534)

[quote]For completeness, Troggan has provided update versions of my loaders that fix the texture size bug (e.g. it now copes with wierd shape images) and also removed depedancy on my GameFrame code :slight_smile:

He’s posted them here:
<urls…>
[/quote]
I’ve only just needed textures (shock! horror!) so before I go and reinvent the wheel yet again I remembered this post. Are these the most up to date versions? It would be nice to have this or something similar as part of the Jogl package, it seems lots of people are using these :slight_smile:

Yep, I think troggans versions are the latest still. Greg did say something about coming back to his versions but not heard anything for a while…

In Theory ™ the texture loaders (the latest ones) should deal with all textures.

Kev

Yeah…putting that stuff into the jogl library would be a very good move. Or at least putting it into the Wikki where everyone finds the latest version.

Well i gave those a try, and failed miserably :frowning: Seems I was getting NULL texture ids constantly. I hacked a quick conversion from one of my LWJGL texture classes and hit the same problem…

Seems to be an initialisation thing, if i delay the loading until the gl canvas has been displayed at least once it works fine.

I’ve not found that you needed display the canvas first, just that you have to wait until init() has been called on GLEventListener.

Kev

I’m back :slight_smile: I’m working on the updated classes as we speak. I had been caught up with JInput OSX, but now that the input stuff is under control and is entering bug fix mode - I’m coming back to this before tackling Joal as it may be more than a simple recompile :smiley:

It would be nice to have the files available for download somewhere on the Jogl-Homepage, if that’s possible.

I’ll have to email the appropriate people about that. While I have permissions to upload those files, they aren’t part of the official core.

Gregory,

Have you taken a look at the changes myself and troggan made based on your original texture loader? (a download link is listed above)

The main part was to remove the switch statement for check the image type and just check an intermediate image of the type GL is expected and copy the source image into that? I was just wondering what you thought, can you see any problems, etc…

Cheers,

Kev

Yeah I took a look at what you guys had done and its good stuff. I had to do some things a little bit differently, but at its core its fundamentally the same approach as what you guys chose (remove the srcPixelFormat as an option for the user and derive it from the texture data). I spent some time putting in AnimatedTextures and QuicktimeTexture extends the AnimatedTexture stuff. All in all - happy happy stuff :slight_smile: