Author Topic: Illuminating objects  (Read 5739 times)

Offline acorn98

  • byte
  • *
  • Posts: 46
    • View Profile
Illuminating objects
« on: February 18, 2004, 01:36:41 am »
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!

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Illuminating objects
« Reply #1 on: February 18, 2004, 05:54:49 pm »
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]


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

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Illuminating objects
« Reply #2 on: February 18, 2004, 06:13:59 pm »
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".

Offline acorn98

  • byte
  • *
  • Posts: 46
    • View Profile
Illuminating objects
« Reply #3 on: February 18, 2004, 10:55:05 pm »
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  :D  Thanks for adding buffer.refresh()!

Offline acorn98

  • byte
  • *
  • Posts: 46
    • View Profile
Illuminating objects
« Reply #4 on: February 18, 2004, 11:33:04 pm »
..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.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Illuminating objects
« Reply #5 on: February 18, 2004, 11:55:54 pm »
Quote from: "acorn98"
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.

Offline acorn98

  • byte
  • *
  • Posts: 46
    • View Profile
Illuminating objects
« Reply #6 on: February 19, 2004, 01:22:09 am »
I've had a look at the fps source - I see what you mean. I'll do it that way. Thanks.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Illuminating objects
« Reply #7 on: February 19, 2004, 11:32:06 pm »
Quote from: "acorn98"
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...

Offline acorn98

  • byte
  • *
  • Posts: 46
    • View Profile
Illuminating objects
« Reply #8 on: February 23, 2004, 10:50:40 pm »
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.

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11745
    • View Profile
    • http://www.jpct.net
Illuminating objects
« Reply #9 on: February 24, 2004, 06:45:31 pm »
Quote from: "acorn98"
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:

Quote
I haven't implemented any collision detection yet
Oh, you actually did: the camera-world collision detection.

Offline acorn98

  • byte
  • *
  • Posts: 46
    • View Profile
Illuminating objects
« Reply #10 on: February 25, 2004, 02:18:50 am »
thanks for the clarification.

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