My guess would be a texture that reflects what one sees when located in the center of the cube looking in n,s,e,w, up and down with a fov of 90°. I don't get that part where you want to make the cube look like a sphere. Why not use a sphere then in the first place?

Incidentally, that would be a nice addition to the Primitives class. It could be as helpful as something you call when you're done with adding all your objects so that it would calculate its own size (any size greater than the biggest object), and it could be its own brand of object (perhaps a subclass to Object3D that is added as a child of the camera so that the sky doesn't change as the player moves around). It's little things like this (and a Math class that would return the angles between two vectors, the pythagorian distance formula, etc.) that jpct is missing.

OK, but I just think a Math class would help. As for the Primitives.getSkyCube suggestion, it could read getSkyCube(Texture front, Texture right, Texture left, Texture back, Texture down) so as to make texturing very easy. A sky cube is something EVERY game uses, so it's not a trivial suggestion in my opinion.

EDIT: Egon, even though you've not been answering, I've been thinking about this for a bit and I think it makes more sense for the sky box to be a FrameBuffer method (FrameBuffer.getSkyBox(Texture front, Texture right, Texture left, Texture back, , Texture up, Texture down)). And maybe its size could be just > or just < Config.farPlane.

I would rather add it to the util-package instead. I don't like moving application specific stuff like sky box of lens flare or similar into the core. I'll consider adding it for the next major release.

No, it's not. I was busy finishing the benchmark for Android. It's the next thing on my list...

Title: Re: Sky Cube Map
Post by: AGP on January 08, 2011, 05:44:31 pm

Thanks a lot. Can I request something else? How about a Time class with methods such as deltaTime() that calculate the elapsed time the last frame and the current? Very all-around useful (especially for keeping animations steady regardless of the hardware).

It's pretty simple to use and takes care of clipping plane adjustment by itself. Just care about your own scene being set up correctly, SkyBox should do what's needed for the skybox.

Concerning the timing request: I'm not going to add this because i don't think that it belongs to the engine. If one wants that and couldn't come up with something on his own, there's plenty of code for this in all my example sources, in the Robombs sources and in the advanced example in the wiki. I might add it as an extra code snippet to the wiki though.

Title: Re: Sky Cube Map
Post by: AGP on January 09, 2011, 01:57:24 am

No, I think ANYBODY could calculate deltaTime on their own, but I also think that the things that are going to be frequently used should be present, that's all, not only to speed up programming but to sort of standardize the code.

public static double deltaTime() {if (lastTime == -100010d) { lastTime = ((double)System.currentTimeMillis())/1000.0d; return 0.00d;//NO TIME HAS EVER ELAPSED IF NO lastTime}double currentTime = ((double)System.currentTimeMillis())/1000.0d;double deltaTime = currentTime-lastTime;lastTime = currentTime;return deltaTime; }}But mine depends on deltaTime() being called (it's the delta of when it was last called. deltaTime() could instead be tied to the buffer.display() method to always return the delta between frames. Sorry for the constant suggestions, you're obviously free to not listen, but don't you think everyday things like this belong in the engine?

I think that it doesn't belong there, because it has nothing to do with graphics and the solution is application specific IMHO. Personally, i've never used your approach with accessing the time directly, but i'm using ticks instead. So for me, this would be useless. Another thing is, how you get the time for your specific application. System.currentTimeMillis() is inaccurate, the LWJGL timer is better, but suffers from problems on some machines where it runs at double the speed. In addition, it's not available when not using/having LWJGL. System.nanoTime() has it's own problems and isn't available for ealier versions. Then there's a way for 1.4 to get an accurate timing out of the sun-packages, which has problems (apart from being "forbidden") with current processors dynamically adjusting clock frequency and so on and so on. I really think that the solution belongs into the application here. What jPCT does, is to provide the possibility to render 3D graphics. Why and when is up to the application to decide. After all, jPCT is no game engine (where this might have its place) but "only" a 3D engine focused on games. That's a slight but important difference IMHO. The other thinking leads to a behemoth like JMonkey and friends where everything is somehow in the engine...

Title: Re: Sky Cube Map
Post by: AGP on January 09, 2011, 07:10:26 pm

I read this statement before from you, and this time I felt like finding out why. It seems that while Unix's time granularity has always been 1 millisecond, Windows 95's was more like 10 (not tragic as I don't see myself measuring units under 10 milliseconds). It's unclear, from what I read, whether they've improved it in newer versions of Windows, but it's safe to say that System.currentTimeMillis() works perfectly on MacOS and Linux, and has only a 10-millisecond margin of error on Windows, right? Sounds accurate to me.

As for your other points, I agree we wouldn't want jpct bloating to jME's size. I'll try to keep my requests to graphics-only in the future. :- )

By the way, is 1024 WAY TOO BIG for the ReflectionHelper? Superman will no longer run since I added that last night. You should add "reasonable values" to the docs.

10ms on single core, 15ms on multi core on Windows iirc. If this is accurate enough or not depends on the application.If 1024 for the reflection map is too much highly depends on the graphics hardware. On lower end solutions, it might be the case but on high end cards, even 4096 isn't much of a problem. The best idea is to let the user decide in some option dialog.

Title: Re: Sky Cube Map
Post by: AGP on January 09, 2011, 08:34:16 pm

But on Mac and Linux it's 100% accurate, right? So that's great already.

Actually, I dropped the number down to 16 and I still get nothing. I'm casting no shadows in the scene but I do have a light right above Superman. And I tested it just now on 4 computers. I must be doing something wrong. I have a single water plane, which I'm passing at construction, and then I just call drawScene() at the end of my draw method. But it seems like it gets stuck at the construction (jpct stops printing out anything and I've let it run for nearly 20 minutes). Is there something else I should do?