Camera clipping, and futurism etc as well as LOD use distance from camera to decide what to draw, and LOD uses it to decide which model to use,
Can we expose item.activeCameraDistance ? I don’t think it could hurt, and for custom LOD and level of logic, I need the property exposed, as the logic for getDistanceTo(camera) in every item adds up. and it’s already calculated for each item right?
You can already get this very easily.
activeCam = bge.logic.getCurrentScene().active_camera
obj = bge.logic.getCurrentController().owner
cameraDist = obj.getDistanceTo(activeCam)
that is a python function, and if I used it for every item, it’s not good, if the distance is already calculated every frame anyway.
it’s exposing something internal,
I can already do getDistanceTo()
as the logic for getDistanceTo(camera) in every item adds up. and it’s already calculated for each item right?
I guess it takes the same amount of time to call up a controller and execute, and retrieve the data,
as to calculate it?
Vec=ownPosition-TargetPosition
D=Vec.magnitude
For some reason, I’m not sure if you’ve yet gotten the idea that the [Dev] prefix should not be used for feature requests.
As for active camera distance, I’m having trouble figuring out a way in which this would not be a redundant feature just because of avoiding two additional lines of Python. Let’s just code a massive horde of built-in logic functions and bloat the code so all of our scripts can be ten lines or less :rolleyes:
If you don’t want to write a lot of Python for complex game mechanics, you can request for Moguri to complete his incomplete components implementation, that will allow you to create a plug and play GUI for any function.
There is no differance I realize, in speed for
cont=Bge.logic.getCurrentController()
own=cont.owner
D=own.activeCameraDistance()
It all eats up cpu the same, (acessing a variable vs acessing two objects and calculating)
Vs
Offset=own.worldPosition-target.worldPosition
D= Offset.magnitude
Vs
Get.active.camera code
own.getDistanceTo(camera)
Using length_squared instead of magnitude will save you processing time
You could also just check the mesh’s name to see what LOD level it is.
Keep in mind, LOD camera distance will only be available for non-culled objects (i.e. objects in view). Hmm, I don’t think there is any LOD API for KX_GameObject, so we could add camera distance, total number of levels, current level to the list. Fortunately, this isn’t too difficult…
I want to use it camera distance and thresholds to manipulate logic tic rates on sensors,
or “Level Of Logic”
or change states would be more efficient I suppose?