www.jpct.net
General => Feedback => Topic started by: Melssj5 on October 05, 2005, 05:00:36 am
-
Hi, I have one sugestion about the engine.
Lights should have more functionality, like moving (translating), a radio maybe they should be able to be joined to an object3D, an aplication for that may be a laser or a misile shoot.
A weakness of this engine are the light efects.
-
You can move lighting sources by World.setLightPosition(),
and you can move the light source along with your moving object (this is how it was done for missiles in technopolies)
-
Yes, I just have noticed that after posting!!!!! :oops: :idea:
But in anyway jpct has no especial efects, like fire o things like that, maybe the lights should have its own methods to do their stuff, I dont know.
-
maybe the lights should have its own methods to do their stuff, I dont know.
Yes, i agree. The current implementation for the lights turned out to be rather unintuitive. The basic idea was to keep Lights as lightweight as possible but that isn't really an issue when looking back at them now. Anyway, i won't change this in jPCT. But it's very easy to write your own wrapper class for the lights. That's what i did in Paradroidz too. All you have to do is to store the World and a light's id in each instance of this "MyLights"-class and map methods like MyLights.setPosition() to the corresponding World-methods. Not an ideal solution but at least more OOish as the current implementation.
-
Hello, I have noticed in my application that there was a limit to the number of lights I can add in a scene (around 40 if I remember).
I suppose there is a way to redefine this limit but I wasn t able to find it.
How to do that?
Manu
-
I suppose there is a way to redefine this limit but I wasn t able to find it.
How to do that?
Set Config.maxLights to a higher value before instantiating a World.
-
Why wont you change that feature on jpct?
-
Why wont you change that feature on jpct?
Because it will break all existing code and doesn't really gain you anything except for giving you the gut feeling that it's somehow "better" that way. One thing i really hate about non-commercial software (may it be open source or not) is when the API constantly changes without adding new functionality, i.e. when the only reason for a change is to make the developers of the API feel better.
But i may add such Wrapper as an option and put it into the util-package. I haven't done this until now, because nobody ever complained about it and because such a wrapper is drop dead simple to write by yourself if needed.
-
but the feature is not only for moving the lights, if having the object Light with its own methods it could help for managing them, for example:
a method to move the lights
a method to remove it from the world
a method to change its colors
a method to change its radio action
etc.
of course this things can be donde on other ways but its not likely to get a Light instance by using an id for managing them from another class. The problem is that I dont know how to get that ID.
-
The id is assigned by World when you call world.addLight()
public static class Light {
private int lightId;
public Light(World world){
this.lightId = world.addLight((new SimpleVector(), 255 255,255))
}
//... put your methods here
//setColor()
//setPosition()
//setIntensity()
}
-
You get the id when adding the light to the World by using addLight() as a return value. Again: I agree that it would be better to handle lights as instances of their own, but just write yourself a Light-class that takes a World in the constructor and internally adds a new light to this world and holds the id. Manipulate the light by mapping the methods of your class to the corresponding ones in World. For example: Currently, there is no way to remove a light from the World, so just add a method disable() to your Light class and let it call World.setLightVisibility(myID, false). Got the idea?
Edit: rolz owned me... :lol:
-
Edit: rolz owned me... :lol:
Hahahah. It was nice infortmation for both! One theorical and one runnable :D.