So I've been looking into spheres and this seems to be a wild subject... couldn't find at least one place that would agree on any proper way to do this.

People say spheres sould be textured with cube maps, and not Mercator streched textures. (like ones NASA gives)

I found this blog post https://mycodingwrongs.wordpress.com/2010/07/24/reprojecting-blue-marble/
The guy reprojected Mercator texture onto Gnomonic cube map.

I was able to texture a sphere with that cube map he gave. I'm not sure if I created that mesh correctly, but it looks quite good.
example: http://dev.keraj.net/sphere/ (press

• on numpad to add more vertices, press V to see wireframe)

1. But I don't know how he did that. How did he reproject from Mercator to Gnomonic. He gave a link to wolfram page on Gnomonic projection, but I am not sure how use that.

2. What if I want to create my own cube map? (ie. procedurally, out of perlin noise, or even manually)

I hope some of you guys been through this and can give me some advices, maybe even some code.
I would really like to know what are good ways to mesh a sphere and texture it procedurally correctly.

Why are you guys sending him to JMonkey? Maybe he wants to know how these things are made? Good programmer should know how things work underneath. Additionaly engines usually assume that you are familiar with these things, so they dont necessarily explain everythig in documentations.

I think good approach would be to take any engine, like maybe Ardor3D, JMonkey. Look at what features they have and what they are showing in their demos and tests. Make research on these features one by one. Google "<feature> opengl how to" etc. Any OpenGL tutorials and guides should suffice. If you can't find anything useful... Ardor3D and JMonkey are open source - you can check the sources. (Warning, if you have no idea on the subjects, watching the sources might be confusing, because even comments and javadoc usually assume you are familiar with these things)

That's what I do, at least.

Only for Chrome? Are you f**king serious?

Can you pack your whole project into zip? I will then run it and try debug your problem.

This OpenGL introduction applies to LWJGL
http://tomdalling.com/blog/category/modern-opengl/ - caution, as it has 7 parts, and not really much is yet explained here but it will get you into OpenGL enough so you can use other tutorials and stuff.

And for Matrix and Camera use LibGDX classes (PerspectiveCamera and Matrix4/Matrix3)
While learning, please use LWJGL directly, don't use LibGDX GL wrappers, they don't support VAO

Do you limit FPS in any way? If you don't, then you'll always eat cpu...

also, the code you have commented uses reflection in a way that will be rather cpu intensive

BufferedImage img = ImageIO.read(YourClass.class.getResourceAsStream("/some/resource.png"));

This will load image from classpath (from inside the jar the application is run)

If you use eclipse, you should select "graphics" folder and add it as source file. (you then can refer to them with path as "/image.png")
later, if you change something in graphics folder, don't forget to refresh workspace in eclipse.

No, the case I tested it with now is the same speed with floats.
Sorry for additional confusion.

@pitbuller: That's probably it!

I used 3 unsigned bytes for coords + 2 unsigned bytes for texture coords.

I just changed vec3 to vec4 and added one dummy value + changed UV to unsigned shorts. So they are all now 4-byte aligned and it went to 300 fps on ATI card.

Thanks!

How could I have missed that best-practices page.

I'm learning OpenGL and decided to make some voxel rendering.

I use VBO to hold mesh for one chunk and I store only visible faces into the VBO
One VAO and one VBO per chunk.

Each chunk is only 32x32 so I decided to use unsigned byte as vertex data instead of floats.
Each vertex is stored with its local position in chunk.
I store chunk offset as uniform and add it to vertex data to render it at correct position.

Performance decreased... mostly visible on ATI cards (its horrible there)

I noticed it is very dependant on number of vertices. As all data is uploaded to VBO, it is clear that it's fail on GPU side.
I removed the lightning calculations to see if they were the cause, but it seems they weren't.

Maybe it's something with shaders having problem converting data types?
It works good with floats, but not with bytes.

Here are my shaders:




They do almost nothing, but they perform hirribly.
Might it be the problem with input data definition?

in vec3 vert; // vertex
in vec2 vtex; // texture coordinate

vec3 and vec2 are float vectors - but VBO contains bytes.. is it really so hard for gpu to convert those types? I don't believe.
Maybe I should have use ivec3 and ivec2 (or uvec3 and uvec2) but if I use them I get veery werid input. deffinitely not what vbo contains.

What my scene looks like you can see in this demo: (light and all the stuff is removed to concentrate on the problem - simple vertex data rendering is horribly slow)
http://dev.keraj.net/czyde/ - it should work with about 900fps .. but it works with 100 on NVIDIA and 15(!) on ATI.

I don't think matrix stack is neccessary for simple things...
He can do it like this.

Sorry I dig out an old thread, but it is not "ended" with proper information.

Java2D can be accelerated (mostly defaultly it is) by Direct3D or OpenGL.

http://docs.oracle.com/javase/1.5.0/docs/guide/2d/flags.html - here you can set some flags to force acceleration (usefult to force direct3d on windows and opengl everywhere else)

BufferedImage when loaded from resources may be INCOMPATIBLE ... there are several types of BufferedImage (depending on layout of pixeldata inside)
For maximum performance, you can create compatible BufferedImage with GraphicsConfiguration
http://docs.oracle.com/javase/7/docs/api/java/awt/GraphicsConfiguration.html#createCompatibleImage%28int,%20int,%20int%29

Java2D tries to cache BufferedImage as texture whenever possible, so drawing it anywhere is as fast as drawing texture.

problem is.. drawing ON BufferedImage is performed in software, while drawing ON VolatileImage is (if possible) on GPU.

so its only faster to use VolatileImage if you want to draw ON IT, otherwise its better to use compatible BufferedImage.

Here is some more info on OpenGL acceleration in Java2D:
http://today.java.net/pub/a/today/2004/11/12/graphics2d.html#Image_Rendering

Direct3D pipeline is very similiar.

@GabrielBailey74: If you "code how you code" then keep it for yourself and dont post bad code on the forums.
Otherwise stop whining if you get corrected.