Illuminating objects

[acorn98]

Is there a way to make an object appear to be 'super-white', regardless of the surrounding light-sources? I'd like to make the entire object appear completely white (RGB=FFFFFF) if possible.

Thanks!

[EgonOlsen]

Well, it's possible to set an additional color for an object (using Object3D.setAdditionalColor(java.awt.Color col)). But lighting is multiplicative when using the OpenGL/SoftGL-renderer and so the object will look like fully illuminated even if it isn't...but it won't look white.
The only way to achieve this, is to replace the texture for the object with a white one (but that's rather slow and works only if the object has one texture only (like an MD2-model or similar)) or by replacing the texture of the object in the TextureManager using TextureManager.replaceTexture(...). Problem with this is, that you'll replace the texture for all objects using this texture. It could be possible to do something like this:

Code Select Expand



// init
Texture t=new Texture(...);
texMan.addTexture("tex1", t);
texMan.addTexture("tex2", t);
texMan.addTexture("tex3", t);

obj1.setTexture("tex1");
obj1.setTexture("tex2");
obj1.setTexture("tex3");

// replace

texMan.replaceTexture("tex1", whiteTexture);
texMan.replaceTexture("tex2", redTexture);
texMan.replaceTexture("tex3", blueTexture);

...

// replace again

texMan.replaceTexture("tex1", t);
texMan.replaceTexture("tex2", t);
texMan.replaceTexture("tex3", t);



But i never tried to add the same texture multiple times to the Manager that way...it should work, but i'm not sure.

Hope this helps.

[EgonOlsen]

OT: Trying out the newest tokima version, i noticed that you still seem to do movement and collision detection in a thread separated from the render loop, because i'm still getting these occasional "hickups", where the level geometry looks wrong for a frame.
I strongly suggest to address this topic as early as possible, because it may lead to really strange bugs in further development (trust me...i've spend two days to find a bug in collision detection when it was triggered from two different threads).

BTW: I really like the tokima website. Looks very "stylish".

[acorn98]

I tried replacing the texture on an object with a white texture, and that worked pretty well, but I then hit upon a novel idea and tried using the new post-processing feature to overlay a white-out effect, and that worked even better.

Yeah, I badly need to restructure the tokima code before I start adding anything really complex. It's on the to-do list.

Did you see the new target/lighting fx? I had some great fun with that..

The v0.98 release is cool    Thanks for adding buffer.refresh()!

[acorn98]

..Thanks for the advice Helge.

I've moved all the movement code into the main thread, just before performing rendering and all the other draw operations.

All the jerkiness has disappeared. *much* better.

[EgonOlsen]

I've moved all the movement code into the main thread, just before performing rendering and all the other draw operations.

All the jerkiness has disappeared. *much* better.

Yes, it's much better this way. However, movement speed seems to depend on framerate now. It's a good idea to keep the timer thread but only to generate "game ticks" and move according to the number of ticks passed since the last frame. The fps-example is doing this for example.

[acorn98]

I've had a look at the fps source - I see what you mean. I'll do it that way. Thanks.

[EgonOlsen]

I've had a look at the fps source - I see what you mean. I'll do it that way. Thanks.

I've just discovered that this can cause problems in cases where the collision detection takes a lot of time compared to the rendering (shouldn't be the case in tokima, so i wouldn't worry about it for now, but maybe it's good to know what may happen). It took me some hours to figure this out and the problem is:

The execution time of the loop that's counting the ticks depends on the number of ticks (go figure... :wink: ). If the collision detection (or whatever there is inside the loop) takes much longer than a tick, you start the rendering with lets say 1 tick already spend on the loop. After the rendering you are at 2 (or 3 or 4...it doesn't matter, because rendering time is independent from the number of ticks passed in the loop). Now you enter the loop with 2 ticks...and that causes the loop to run for at least 2 ticks, because one run takes 1 tick in this example. So we start the rendering with 2 ticks and 3 ticks have elapsed after it. Now we enter the loop with 3 ticks...and it takes 3 ticks to complete...and so on. In the end, we are at a tick-count of 50 or 100 or 1000 when entering the loop and we can start measuring in seconds per frame instead of frames per second.
To summerize this: The problem may occur if the loop executes in more than one tick over a longer period of time. I've never experienced this problem when running around in Quake levels or similar but i ran into it when doing a lot of collision detection stuff in the loop. Keep this in mind...

[acorn98]

Sorry for the late response..been hard at work  :cry:

Not sure I understand - it's seems very complex! I wasn't sure how the problem manifests itself - are you saying that the collision detection becomes inaccurate when it exceeds a tick?

I haven't implemented any collision detection yet, but it'll have to go in soon so I'll keep an eye out for any unusual behaviour.

[EgonOlsen]

Not sure I understand - it's seems very complex! I wasn't sure how the problem manifests itself - are you saying that the collision detection becomes inaccurate when it exceeds a tick?

No, it doesn't get inaccurate and yes, it seems to be complex...but it isn't. The problem lies in the way the movement of the camera and/or objects is synchronized with the framerate. The current approach assumes that collision detection doesn't consume much time compared to the rendering itself. It's a bit difficult to understand...that's why i wasn't aware of it for some time (and maybe why i killed a thread in another forum with this question... :wink: ). An example: Imagine your job is to make one step forward for every second that has elapsed (that's the "collision detection") and then say "blahblah" (that's the "rendering"). You start at 0, so you just say "blahblah". After that, 1 second has passed and you make one step (which takes a second too in this example) and say "blahblah" again. Now you have to make 2 steps, because two seconds have passed since the last time you moved forward (one during the first step and one while saying "blahblah")...then you have to make three steps, then four...and finally, you are just walking forward without saying "blahblah" in a reasonable time. If we modify this example and assume that the step takes not one second, but 1/10th of a second, it's no longer a problem.
I think a solution would be to ignore the time spent in the collision detection and just count the rendering time. This may lead to slower movement in some situations where a lot of collisions are taking place, but does that really matter...
Anyway, i don't think that this will happen to you...i never happened to me except in a special test case. But if it ever does, you may remember this thread... :wink:

I haven't implemented any collision detection yet

Oh, you actually did: the camera-world collision detection.

[acorn98]

thanks for the clarification.

..glad to see jPCT works with Knoppix. Highly portable, eh?  :wink: