koobas.hobune.stream
raycasting performance wise
hi im still trying to learn the best way of raycasting, im currently using it with my own gui system and was wandering which method is the best perfomance wise to cast a ray?
so at the moment my script looks like this
for(var i = 0; i <Input.touchCount; ++i){
var touch = Input.GetTouch(i);
var ray = Camera.mainCamera.ScreenPointToRay (touch.position);
var hit : RaycastHit;
var guiLayer = 1 << 10;
if(Physics.Raycast (ray,hit,Mathf.Infinity,guiLayer)){
// Debug.Log(hit.collider.gameObject.name);
if(hit.collider.gameObject == Object){
do stuff
}
}
}
but i have seen another method of using switch,case any advice
also on some things i will have a touch phase as well
ins$$anonymous$$d of posting a new question i was also wandering if it would be better to use a number ins$$anonymous$$d of infinity
Is it very expensive in your particular scene? What sort of colliders are you using? Changing from infinity will just check less objects, so if you don't $$anonymous$$d your fingers "reaching out as far", then it could potentially be a little bit faster, but profile it to be sure.
currently i dont own pro, so trying to learn the best approach to doing things, then i dont pick up bad habits. ive had to change my entire gui system just to reduce draw calls. game ran fine no lag on phone but the game itself is very fast moving with a lot of physics being used, explosions and stuff. so get the performance right first time will help when i want to make it on older devices. (wont drain the battery as much as well)
on one level i had almost a hundred draw calls, i was shocked it even ran on a mobile so well, doubt it would be the same for a phone like the 3gs, which is still a very used phone.
but for my gui its just simple box colliders about 10 controls all supporting mult touch. inside a separate camera orth view i think. infact if u use ngui its basically that but with my own script to call the colliders.
just to note the 100 draw calls have been significantly reduced, i just wanted to see if it could handle it
For 3D touches I have an IInteractiveObject interface that other scripts can implement to handle touch events and instead of comparing objects and then 'doing stuff' I look for the component on the collider and if present I call the relevant method, effectively delegating the behaviour of that touch action to the object that was touched (or the type rather, as I have only a handful of interactive object types). Although I use this for 3D, you could use the same kind of thing for UI.
My code looks something like:
BVInteractiveObject interactive = object_hit.GetComponent<BVInteractiveObject>();
if(interactive != null && interactive.ClickDistance >= hitInfo.distance) interactive.Clicked();
Apologies as this is C# code - I don't know the equivalent javascript.
As you're only ray-casting a particular layer, you probably want all colliders in that layer to be considered, so it is likely to make little difference having infinity or a particular depth. If you extend to ray-casting into the 3D view, then you probably want to be able to configure which cameras to use, which layers to consider and how deep the touch should go.
As an aside...
For your GUI, it is a common practise to create a texture atlas so that you can (in theory) draw the whole GUI in 1 draw call - this is a very good way to improve performance on mobile as there are fewer draw calls and state changes (changing the material for each button for example). I don't know if you're doing this?
This should be the equivalent JS:
var interactive = object_hit.GetComponent(BVInteractiveObject);
if(interactive != null && interactive.ClickDistance >= hitInfo.distance) interactive.Clicked();
It's worth noting that finding a component is probably actually less performant than comparing GameObjects, but a:) you're not going to be doing this hundreds of times a frame and b:) comparing GameObjects doesn't scale and you probably won't be able to re-use your UI code later on.
Thanks for the information im currently learning csharp and java, i was thinking of looking for the object inside a tag ins$$anonymous$$d but either way it stores in a varable. And yes the whole idea of this is so that i can use an atlas to reduce game size and draw calls.
Thanks for a detailed description of checking a hit a different way.
Yes, if you put the things you want to be able to 'pick' with the mouse or touch on a mobile device, you reduce the number of colliders that need to be considered, so it will give you some performance gain - it's just good practise: do it at the start and you don't have to go through and retro fit it later if you have performance issues.
I figure I'm trying for a balance between what I learn and what I help with :) Damn gamification though... $$anonymous$$eeps you co$$anonymous$$g back ;)
