koobas.hobune.stream
Activate Game object when in Camera view and deactivate when out of camera view.
Hello,
I want to activate the gameobject when it enters in to my camera view. I know the solution for deactivation using OnBecameInvisible().
OnBecamevisible() is no use for me as the game object is already deactivated and it won't be called.
Any other solution for this scenario. I have many game objects around 18k. And it should be compatible with iPhone3gs. Because of many game objects My game legs.
18,000! WoW... WOW.. are you sure so many are needed? There must be a way to simply this first off. I don't know if there is a native way, but what's wrong with setting a bool to skip the body of Update function, and setting the bool again after it becomes visible rather than shutting it down completely? I mean, you can check all 18K objects angles relative to the camera forward (and add distance in there perhaps), but you are still checking 18k objects every frame or so (hopefully not every frame). I mean, consider modern RTS games - it's amazing they have a few hundred active entities, and they are optimized in every way for a PC in C++.
anyway, another way, is to group them if possible (if they can be grouped by remaining int eh same area)- make one a parent, shut the children down, leave the parent running to check when it's visible again, and it can activate/deactivate the children when it is.
18,000! Your next post question needs to be 'How can I reduce 18,000 active entities if I'm doing..." :)
I had a problem like this one lately. I hope this will help you:
void Start() {
InvokeRepeating("MakeVisible", 0.0f, 0.5f);
}
void MakeVisible() {
if(gameObject.activeSelf == false) {
if(Camera.current != null) {
Vector3 pos = Camera.current.WorldToViewportPoint(transform.position);
if(pos.z > 0 && pos.x >= 0.0f && pos.x <=1.0f && pos.y >= 0.0f && pos.y <=1.0f) {
if(isDebug) Debug.Log (pos.ToString("F4"));
gameObject.SetActive(true);
}
}
}
}
Another solution may be to use the GeometryUtility class.
This is fine for a few objects, but for 18k, it won't help his problem. this is still a lot of calculation on the cpu side for essentially doing nothing. if you want to do it, as i suggested above, get the difference in positions is cheaper, (you have the field of view, and know the positions of camera and object for a cheap angle check) for 18k active entities i still don't recommend this faster method, and still don't recommend 18k entities.
In CryEngine, you can pause entities when they aren't in view, or when loded out..this is essentially what he wants, and there may be a way to do it natively..
He needs a way to group them, into zones (trigger areas) for instance if that is possible..if you enter a zone, it will activate entities within that zone, if he leaves it will deactivate them (the would have to overlap for smoother transition)
But that's not the real problem.
The biggest problem is 18k 'active' entities on IOS. already be a problem unless they are triangles or boxes.. say you see about 1/3rd at one time, that's 6k meshes. polygon budget is what, 50,000? so average must be under 10 verts? It's likely lagging for a few reasons...what draw calls are you producing?..ps3 you can only do 2000 drawcalls already.. I think it's around 50-100 for ios. 18k entities, u can only have 100 with a single texture, thus 180 duplicates of each type..unless they're really low res and using atlases well...not to mention gui, particle effects, etc aren't even budgeted with these assumptions.
Thanks for the answer.
Sinister : This 18k game objects are just cubes with colliders. I haven't applied any scripts on them yet. This 18k objects are 134 * 134 grid. I have thought of the solution grouping and assign them under parents but The problem is grouping I can't think of an idea how should I group them ?
what kind of drawcalls are you producing? if you don't have any scripts attached yet.. I don't know the details of your game well enough, are they confined to an area? does the grid affect their positions? can they move (with physics or other?).. what are they for? why are you needing so many? are some always visible? are some rarely visible?
Also note, having physics on objects is way more expensive than just drawing objects.. there will be a bottle neck here as well much much faster than polygon counts - as physics is a cpu-side operation. Did you test it running without the colliders? and with half with colliders and not? Test it out.
Box colliders (AABB) only take a single check per cycle,if you using complex shapes tho it can add up fast. think about a game like crysis/call of duty, they seem to have more complex physics, but usually they are using as many box colliders and sphere colliders/capsules as possible, and they load in and out the physics system in a small area around the player well. ios has a much weaker everything and you're already pushing it high for PCs.. You are lagging testing on a PC yes? Definitely on an ios device.
