Sky Cube Map

[AGP]

What should a sky cube's map look like? And what should be called (like Object3D.calcTextureWrap()) so that it looks like a perfect sphere with no odd distortions?

[EgonOlsen]

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?

[AGP]

Less polygons. It's usually how it's done (you can't see the edges of the cube is what I mean by it looking like a sphere).

[AGP]

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.

[EgonOlsen]

Actually, you can calculate the distance and angle between vectors and such already...just use the methods in SimpleVector.

[AGP]

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.

[EgonOlsen]

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.

[AGP]

Thanks a lot, the util package sounds good (trust me, it's far more useful than some of the other stuff you ended up putting in).

[AGP]

Hey, Egon, just wondering if this is already in a beta. Happy new year, by the way!

[EgonOlsen]

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

[AGP]

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).

[EgonOlsen]

Here you go...

Jar: http://www.jpct.net/download/beta/jpct.jar
Doc: http://www.jpct.de/download/tmp/skybox/SkyBox.html (just that one page ripped from the docs, the internal links won't work)
Example textures: http://www.jpct.de/download/tmp/skybox/skybox.7z
Prove that it works:



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.

[AGP]

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.

Case in point:

Code Select Expand

class Time {

     private static double lastTime = -100010d;

     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?

Thanks a lot for the skyBox.

[EgonOlsen]

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...

[AGP]

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.