Jump to content
UnitySpain

Aceptamos donaciones vía Paypal.

UnitySpain.com es un servicio gratuito, pero mantener la Comunidad conlleva una serie de gastos.

Fondo Anual Unityspain: Donados 15,00€ de 150,00€

  • Servidor: Dominio.com y Hosting Web
  • Mantenimiento de los Foros
  • Contenido y Servicios Extras
  • Mantenimiento para Redes Sociales
Sign in to follow this  
lightbug

Raycast vs Boxcast (resultados)

Recommended Posts

La intro:

Hola, he realizado una prueba que me ha sido útil en el proyecto que estoy haciendo y ya que estaba muy ocupado quería compartir los resultados obtenidos :12_slight_smile:.

La cuestión es así, hace ya un tiempo que estoy diseñando un Character Controller 2D 100% kinemático (osea sin rigidbodies dinámicos, puede operar también sin rigidbody, el componente está ahí por si se quieren usar triggers y demás... pero NO es "necesario"), es decir que la detección de colisiones se realiza a mano, mediante disparar rays, spheres, boxs, o lo que sea que ayude a determinar que objeto se interpondrá en el camino del personaje, y en base a ello desplazarlo. Dentro de la parte de CollisionDetection tengo la opción (desde que lo arranqué) de elegir por RayCast (con rays horizontales y verticales) o por BoxCast (con la opción del grosor de la caja a disparar). La ventaja clara de la caja es que barre en toda su longitud (osea no quedan agujeros), un boxcast equivale a hacer un sweep de rays (refiriendome al resultado , NO al método!!), entonces te permite muchisima más precisión (que sea o no necesaria es otra cuestión).

-> De aquí la pregunta que me hice, por que sigo incluyendo el raycast? será que el rayCast es "performance-friendly" cuando la caja, a expensas de su precision/resultado te asesina?...

La demo:

La demo consiste en instanciar una cantidad X de cubitos (los personajes de prueba que estoy usando) inmóviles (para esta demo) que solo están "Casteando" sin sentido a los 4 lados (Norte sur este oeste), la idea principal es medir de alguna manera quien gana en precisión (obviamente el boxcast) y en performance (suprise motherf...) . El otro propósito de esta demo es la de demostrar que no hay que tenerle miedo al raycast, mucha gente piensa que podés tirar maximo diez, en las pruebas que realicé con esos cubo/personajes logré alrededor de 60 fps disparando algo así como 15000 rays! en una PC de gama media/baja (mas baja que media :16_relieved:), y por supuesto sacando de lado que para cada resultado de la colision se calculan/aplican otras cosas más, senos, cosenos, tangentes, arcotanges, y demás (útiles para el character controller). Claro que eso no justifica tirar rays o de más, sobre todo si estás en dispositivos moviles, pero tampoco hay que temerles tanto.

De acá se puede descargar por si quieren probar ustedes mismos:

https://drive.google.com/open?id=1_YgnuT3NEWFoLJVPSskXwbRekLpmSjpT

  • E, R y T cambian de método
  • Click : instanciar 1 Personaje
  • M : Instanciar 100 personajes
  • Enter : Full reset
  • Escape : Salir

Puede existir algun que otro bug, sobre todo porque estoy remodelando el tema del controller y las colisiones, pero para el objetivo de este test son irrelevantes.

Los Resultados (FPS):

- Obviamente sin Vsync y usando la Build, en Editor los valores grandes bajan mucho más, los valores mayores a 50 se mantienen parecidos, lo cual es lógico por el mismo overhead del Editor

- Sacar de lado que se usa OnGUI para redibujar la GUI (FPS + instrucciones) y que además las strings se concatenan con el "+=" (estaba muy pancho), todo en conjunto forma el asignador de GC allocations por preferencia de Unity (6.2 KB ), así que no se que tan mejor pueda ir la cosa si se hace bien, pero tampoco es que sea crucial esto para esta prueba en específico.

- Los valores extremos que se ven de 1 a 50 personajes son totalmente lógicos, quieren decir que la parte de colision del método no influye en nada frente a otros posibles factores: networking, gráficos, AI, luces, físicas, FX's, ---> intencionalmente no hay ninguno de estos , tener en cuenta que la escena es 2D, sin nada, solamente el raycast/boxcast afecta el rendimiento:

Capture.JPG

Al agregar de a 100 de golpe (naranja = Physics , celeste = Scripts , verdoso (?) = GC)

profiler.jpg

Como se puede ver el BoxCast funciona mejor a nivel fps y además se comporta mejor para casos extremos como el siguiente (no que sea útil en un juego real, pero andar va a andar bien):

GIF_RayVSBox.gif

La Conclusión:

Es muy probable que tire la opción del Raycast a la basura ya que:

  1. Se comporta peor en todo sentido.
  2. Está bien que no tiene sentido tener 400 jugadores, pero debería ser mejor que el boxcast (por lo menos en performance) para , no se, 10 jugadores en pantalla? (un escenario bastante real player + npc's por ej), y no lo hace.
  3. Programar la caja es mucho más rápido y fácil.
  4. No conozco otros Character Controllers basados en BoxCast.

 

 

Edited by lightbug

Share this post


Link to post
Share on other sites

Muchas gracias por tu aporte sobre este Interesante recurso. Lo estudiaremos a fondo, a ver hasta qué punto es un compromiso de rendimiento...

Share this post


Link to post
Share on other sites

Deja que te pongo a caldo!!! xDDD

Bromas aparte, los raycasts como dices se pueden tener 1000 facilmente en "cualquier pc", asi que tener un character controller con los tipicos 16 rayos no es un drama.

El boxcast al hacer un barrido es mas "preciso", pero al ser una caja, por ejemplo en un slope ya lo tienes mas jodido si quieres acercar algun pie con IK, con lo que descartado xD

Imagino que has usado las versiones nonalloc de los raycast o cualquier otro metodo (son "nuevas" en unity y ya no crean GC) como el physics.raycast de toda la vida

Share this post


Link to post
Share on other sites
1 hour ago, Eskema said:

Deja que te pongo a caldo!!! xDDD

xD ponga nomás que para eso hice el topic!

53 minutes ago, Eskema said:

Bromas aparte, los raycasts como dices se pueden tener 1000 facilmente en "cualquier pc", asi que tener un character controller con los tipicos 16 rayos no es un drama.

Totalmente, la cuestion es que, para este caso no tendría sentido usar los rays (en base a mi experiencia) por el "agujero" de información que te deja (no que sea relevante en un escenario real, con 12 rayos (h=3, v=3) cubrís muchos casos de juegos conocidos 2d), la caja no se bien que algoritmo usará aunque asumo que sera un AABB pero la versión proyectada en ejes distintos a los "ejes alineados", no recuerdo bien su nombre ahora pero basicamente consiste en barrer un AABB torcido, por eso el algoritmo en sí es mejor en términos de resultados, y además es más sencillo de realizar (los números lo demuestran). Puede ser que la caja en algún momento me traicione  o que ocurra alguna situacion en la que los rays sean ventajosos, pero bueno, por ahora la banco :12_slight_smile:.

Una vez, a modo de prueba quise implementar mis propios algoritmos de colision 2D, fue divertido. Terminé obviamente haciendo los básicos AABB - AABB, Circle - AABB, Circle - Circle , etc... cuando llegué al Ray/Circle (el más sencillo) me quedé congelado, llené hojas y hojas de calculos, no sabía como resolver el problema, me crucé con un libro excelente en donde se explicaba este método (y muchos otros más), y si, claramente era mucho más enredado que un AABB (como era de esperar), ni te cuento de un ray vs polygon.

 

56 minutes ago, Eskema said:

El boxcast al hacer un barrido es mas "preciso", pero al ser una caja, por ejemplo en un slope ya lo tienes mas jodido si quieres acercar algun pie con IK, con lo que descartado xD

Con el tema del Slope y el IK, Si, es válido, pero la idea del controller desde sus cimientos, como yo lo veo/quiero implementar, y además basado en los ya estudiados, es la de proponer detección de colisión + respuesta básica ante la entrada del script que está encima, osea, cosas relevantes para él como manejo de slopes, está en el aire o no, ground clamping (o algunos lo llaman ground snaping creo (?)), está tocando un muro a la derecha, está sobre la slope no permitida izq, etc...  Si implementara manejo de IK's seguramente lo haría por encima del controller, pensando en la parte gráfica/animación directamente, por supuesto con raycast toda la vida, supongo, la caja no serviría (o por lo menos no le haría frente al raycast), aunque nunca toqué IKs.

 

57 minutes ago, Eskema said:

Imagino que has usado las versiones nonalloc de los raycast o cualquier otro metodo (son "nuevas" en unity y ya no crean GC) como el physics.raycast de toda la vida

En este caso no las usé porque no me sirve, ya que las versiones non alloc se usan para casos en los que necesitás info de varios colliders (por eso la tienen los overlap's) y guardar estos colliders en algun contenedor, pero está muy bien que las traigas a la mesa, ya que en mi intento de character controller 3D (con un capsule) tuve que recurrir a usarlas, gracias al método de ComputePenetration (dios te bendiga), en donde movía y depenetraba.

Por la naturaleza del 3D más la falta de control sobre el capsule collider podía quedar atrapado en casos muy feos, así que hacía un overlap con non-alloc, pesaba las influencias de todos los colliders involucrados y aplicaba la depenetración correspondiente...en este caso (2D) la caja se dispara y solo interesa el primero que toca, el método que uso consta en Proyectar en el aire, y depenetrar en suelo, pero al ser 2D y usar un BoxCollider2D tengo control de todas las direcciones, cosa que con el capsule del 3D no tenía (ni con el 2D tampoco), por eso es que no las usé.

El Controller de la demo que hice no genera nada de GC :5_smiley: (o por lo menos casi nada, miro el profiler muy de vez en cuando y no he encontrado, proveniente del controller), es más solo me genera GC (en la demo) la GUI, las strings concatenadas mal (no usé el string builder aunque también genera GC), los prints (en Editor no en la build, claro), y algunas cositas más que Unity tiene ganas de mandarme GC (algo de Post Audio  bla bal ?? y quizás otra que no recuerdo) pero en total no es casi nada, OnGUI es lo que más tira en este caso, fijate los picos cuando meto de a 100 personajes, está bien que están todos instanciados con "Instantiate", (no iba a hacer una pool solo para la demo), de ahí supongo vendrán los picos, el resto es todo OnGUI :52_fearful:.

Saludos

Share this post


Link to post
Share on other sites

Normalmente en los 2d o 2.5d con los raycasts al menos tiras 8 en horizontal y 4 en los pies + otros 4 en la cabeza (para techos/plataformas), tu 3+3 se me queda corto xD .Sobra decir claro que solo tiras los rayos laterales y los del suelo, el del techo lo dejas para cuando saltas. 

Usando el boxcast lo solucionas con 3, lateral y suelo/techo.

Mi miedo siempre con los boxcasts es el tener que asegurarte que sea AABB para que todo este alineado y no te de alguna respuesta "rara", y que por ejemplo para escaleras/slope no me gusta el box porque puedo tener varios rayos en la pierna y segun la altura de colision le dejo subir el escalon o no. Si me colisiona el box ya tengo que ver en que punto colisiona y hacer los calculos pertinentes, que suele ser mas rollete.

 

Yo ahora mismo estoy haciendo un shooter top down, y me he creado un controller con rigidbody (movido con addforce como toca) y raycastsnonalloc para los disparos por ejemplo y me sobra por todos los lados. La caja no la vi relevante (no digo que pueda serla), ni tenia ganas de complicarme la vida mas. Con la fisica "normal" conseguia el efecto deseado :)

 

Share this post


Link to post
Share on other sites
2 hours ago, Eskema said:

Normalmente en los 2d o 2.5d con los raycasts al menos tiras 8 en horizontal y 4 en los pies + otros 4 en la cabeza (para techos/plataformas), tu 3+3 se me queda corto xD .

Bueno si el 3x3 te queda corto dependerá de lo que quieras hacer. El 3x3 es lo más básico que existe, yo no los usaría, pero tomando algunos ejemplos de juegos reales y basandome en sus escenarios (a ojo ... ojo xD) se puede inferir que siempre tenés casos bastantes amigables o por lo menos lo diseñadores de niveles son bastante vivos en esto, por lo que con el 3x3 estarías "bien", pero al límite, obviamente qué mejor que meter algunos rayos más, a mi me gusta mantenerlo impar para tener extremos y medio, Ej 7x5. usaba mucho en un tiempo.

El 3x3 lo metí solo para medir un raycast super base frente a otro, el de 12 x 5 para representar un caso algo "extremo" (para las dimensiones del personaje), con objetivo de tender a lo detectable por la caja, y bueno la caja que sería la posta hablando de detección.

Quote

Sobra decir claro que solo tiras los rayos laterales y los del suelo, el del techo lo dejas para cuando saltas.

Dependerá de lo que quieras hacer, de si estás solo o si existen otras entidades interactuando entre sí... En mi caso al proyectar (en aire) los disparo así como decís, pero en suelo no, podría y lo he hecho por mucho tiempo, pero igual disparo en 4 direcciones: arriba y abajo por algunos casos bastante únicos (te tendría que pasar imagenes detalladas para que se entiendan) en los que mantenés el groundclamping con el de abajo y con el de arriba evitás meterte en figuras bien raras al bajar por ej (otra vez, casos algo irreales, pero estaban en mi cabeza en ese momento) e izq + der, uno correspondiente al lado donde me estoy moviendo (tiene lógica), el otro por el tema de plataformas que te empujan, o enemigos o lo que sea (también ayuda el de arriba). Si no uso esto podría hacer algo parecido y que cada plataforma calcule la cantidad de dezplamiento al empujar, basicamente lo mismo pero ahora la plataforma hace el ray/boxcast, por esto dejé que el mismo personaje lo haga, es más cómodo, menos lío de implementar y el resultado es el mismo (y un resultado muy util a nivel de gameplay).

Por supuesto esto se puede dar como una opción en todo momento, incluso el character Controller de Unity tiene algo parecido con esto :

https://docs.unity3d.com/ScriptReference/CharacterController-enableOverlapRecovery.html

Proyecta y luego si está activo te depenetra, Ojo lo hace terriblemente mal !!! :6_smile: pero lo hace. Hará el computePenetration de arriba supongo.

 

2 hours ago, Eskema said:

Mi miedo siempre con los boxcasts es el tener que asegurarte que sea AABB para que todo este alineado y no te de alguna respuesta "rara", y que por ejemplo para escaleras/slope no me gusta el box porque puedo tener varios rayos en la pierna y segun la altura de colision le dejo subir el escalon o no. Si me colisiona el box ya tengo que ver en que punto colisiona y hacer los calculos pertinentes, que suele ser mas rollete.

Si le pasas el angle podés girar el box, no se si es eso a lo que te refieres con lo de todo alineado? yo lo uso para el personaje en distintas gravedades, el personaje gira X grados y todo sigue funcionando bien.

Bueno el tema de la escalera está genial como lo proponés, pero con la caja puedo hacer lo mismo, en sí dependerá del método que uses, yo puedo manejar steps lo más bien con la box, subir y bajar en base a la altura del step, básicamente el boxcast estrella es el de los pies (en mi caso), el que te prohibe subir por una slope de 0.01f grados hasta el que te permite subir/bajar escalones de 2 m de altura (mucho más alto que el personaje, totalmente irreal y bien exagerado pero es posible :12_slight_smile:).

Que podés hacer con el raycast que con el boxcast no? algo que se me ocurre y que está muy bueno, disparás 5 rays, promedias el angulo y en base al resultado alineás el personaje, ese efecto queda muy bueno.

2 hours ago, Eskema said:

Yo ahora mismo estoy haciendo un shooter top down, y me he creado un controller con rigidbody (movido con addforce como toca) y raycastsnonalloc para los disparos por ejemplo y me sobra por todos los lados. La caja no la vi relevante (no digo que pueda serla), ni tenia ganas de complicarme la vida mas. Con la fisica "normal" conseguia el efecto deseado :)

la caja para el personaje decís? si estás disparando claro, lo mejor es un raycast, y el non alloc lo usas por los multiples "hits" ?

Share this post


Link to post
Share on other sites

Lo del miedo a los boxcast es que todos queden alineados, si rotas el personaje y la colision no tomas en cuenta la rotacion se te puede ir todo al carajo, aunque claro depende del juego, en un topdown "marcianitos" como un galaga te trae sin cuidado que las cajas sean de tipo AABB, con hacer caja con caja vas que sobras sin importarte la rotacion.

Segun como tires el boxcast puedes tener en cuenta que sea AABB o no, y si te "olvidas" de que sea AABB (por la razon que sea), luego te encuentras con que el juego hace extraños y te vuelves loco xD de ahi que prefiera usar el raycast, o un spherecast si me apuras y necesitas un rango mas amplio que una simple linea.

 

Lo de la escalera/slope, yo suelo tener 8 rayos en horizontal, y 3 de ellos en la zona de las piernas, 1 un poco por debajo de la rodilla, otro por encima del tobillo, y el ultimo por encima de los dedos (para no estar pegado al suelo claro).

En funcion de cual de esos 3 hace hit con lo que tiene delante se que tipo de "escalon" tengo (por la altura) y decido si le dejo subir o no. Esto como bien sabemos depende claro del juego que hagas, nunca hay una solucion buena para todo.

El non-alloc lo uso para 1 solo hit por ahorrar el allocation que hace de cada hit (para el parametro out), que aunque son structs y vayan en la heap terminan consumiendo y creando GC cuando no hay mas espacio. Por eso ya que los de unity por fin atendieron al feedback de la gente los uso en cosas "intensivas".

Si voy a hacer solo 1 rayo por ejemplo para coger un objeto, pues probablemente no perderia el tiempo con el non-alloc.

 

La caja para el personaje me referia, es decir hacer el tipico controller de rayos o de boxcast. Estar disparando rayos o cajas no me interesaba, asi que opte por usar un rigidbody normal y su gravity, todo movido con el addforce me permite tener el feeling que buscaba mientras tengo colisiones con todo el escenario sin preocuparme mucho. De hecho lo he modularizado y tengo una clase "movement" que es la que mueve una transform o rigidbody (lo que le pases) y asi el controller esta mas separado y desacoplado del resto de clases

Share this post


Link to post
Share on other sites
2 hours ago, Eskema said:

Segun como tires el boxcast puedes tener en cuenta que sea AABB o no, y si te "olvidas" de que sea AABB (por la razon que sea), luego te encuentras con que el juego hace extraños y te vuelves loco xD

Ah jaja, sí, me pasó cuando le metí la gravedad cambiada (otras direcciones distintas a Vector2.down), había odiado al boxcast por esto hasta que apareció el angle, en 3D tiene otro nombre pero es basicamente lo mismo.

 

2 hours ago, Eskema said:

La caja para el personaje me referia, es decir hacer el tipico controller de rayos o de boxcast. Estar disparando rayos o cajas no me interesaba, asi que opte por usar un rigidbody normal y su gravity, todo movido con el addforce me permite tener el feeling que buscaba mientras tengo colisiones con todo el escenario sin preocuparme mucho. De hecho lo he modularizado y tengo una clase "movement" que es la que mueve una transform o rigidbody (lo que le pases) y asi el controller esta mas separado y desacoplado del resto de clases

Claro esa es la idea, en mi caso yo tengo (entre varias versiones que hice, esta es la que más me convenció): un monobehaviour maestro (el Character Controller) que basicamente es el encargado de coordinar todo manejando estados, condiciones entre estados y al finar dar la orden del "Move" típico de esos componentes, (mucho más un indicador de flags que una maquina de estados propiamente dicha), el "Character Motor" (una clase C#) que es el que recibe la orden de moverse una "delta" y hace todo el trabajo feo de fondo (translate, flags, llamadas a delegates (por si desde afuera estás escuchando "OnEnterMovingPlatform" ponele)). El resto de los componentes son "add-ons" si se podría decir, que escuchan a estos "estados", también clases genericas de C# divididas en poses (agacharse, cuerpo tierra, etc) y acciones (movimiento horizontal, gravedad,saltar, dash, nadar , etc),  cosa de que sea fácil expandirlo, por ej si querés hacer una pose propia y/o acción personalizada en X estado.

Share this post


Link to post
Share on other sites

esta muy bien todo esto...

para 3d existe tambien boxCast... nunca lo habia usado pensando que no seria "performance-friendly" come el rayCast...

yo soy amigo de usar rayCast/sphereCast para todo... 

al leer este post me entran varias dudas acerca del rendimiento en 3d... puesto que si pasa igual que en 2d, el boxCast (3d) quizas no sea tan "performance-killer" como pensaba, y quizas en alguas cosas me convenga echar boxCast en vez de rays... o spheres... y... sphereCast es tan amigable como rayCast? porque uso casi mas las spheres que los rays... 

el los plataformas 2d, 2.5d uso habitualmente 4 spheres... o como mucho igual 6... o dependiendo de como sea el juego igual requiere mas..

pero porejemplo en el juego de coches para android que estamos haciendo, cada coche (hay 6) tira 17 sphere cast (contando una para cada rueda) y el rendimiento es muy bueno:) ...pero quizas se podrian cambiar varios de esos spherecast por un boxCast... :35_thinking: ...y "aligerar" aun mas la "carga" del procesador...

Share this post


Link to post
Share on other sites
Just now, Igor said:

al leer este post me entran varias dudas acerca del rendimiento en 3d... puesto que si pasa igual que en 2d, el boxCast (3d) quizas no sea tan "performance-killer" como pensaba, y quizas en alguas cosas me convenga echar boxCast en vez de rays... o spheres... y... sphereCast es tan amigable como rayCast? porque uso casi mas las spheres que los rays...

Ahora mismo estoy haciendo un hibrido del Character 2D que tengo, cosa de con cambiar una opción podés usar un BoxCast (3D) en vez de un BoxCast2D

meeee.jpg

En cuanto termine y quede todo pasable (hay algunos bugs de momento) tengo pensado hacer algo parecido al test anterior para BoxCast3D vs RayCast 3D y así estresar todo y ver que sale:12_slight_smile: . Pero de entrada podría estimar que el boxcast ganará nuevamente.

 

8 minutes ago, Igor said:

pero porejemplo en el juego de coches para android que estamos haciendo, cada coche (hay 6) tira 17 sphere cast (contando una para cada rueda) y el rendimiento es muy bueno:) ...pero quizas se podrian cambiar varios de esos spherecast por un boxCast... :35_thinking: ...y "aligerar" aun mas la "carga" del procesador...

Me parece que un sphere cast es más rápido que un boxCast, hacé la prueba sino ;)

Un ray cuesta, ya que el calculo físico tiene su complejidad (ray vs polígono por ej), un "sweep"(boxcast, spherecast, etc) incluso puede que cueste más (tendría que ver la matemática de fondo pero asumo que así será)... pero aclaro, este test no es para alentar que cada uno reemplace cada ray(en general) por su versión "Sweep".

En este caso, el problema es el espacio entre los rays, por ej para tener "el mismo" resultado (nunca termina igual pero bueno) usar un ray sería como pisar con un pie que ocupa un area de 1x1cm2 (siendo toltamente generoso, esto debería ser de 0.00001 x 0.0001 cm2 ponele, pero para el calculo va bien), cubrís un metro en horizontal con 100 rays cuando usar un boxcast sería como pisar con un pie que ocupa un area de 1x1 m2 , es decir con uno me alcanza. Entonces lográs lo mismo con un Box vs 100 Rays (en realidad con 100000000.... rays) ni hablar que después tenés que hacer calculo adicional para encontrar al "ray ganador", y acá es donde la diferencia se hace notable, no solo en resultado, sino en performance, es abismal uno vs otro  ...

...pero ... pero...

... podrías decir, "barbaro con pocos rays me alcanza, que tanto más cuesta usar el box vs 1 ray?"  notás que para los rays de 3x3 vs boxCast (12 rays vs 4 box) sigue ganando el box, entonces para tener resultados aceptables en el entorno de un juego 2D, sabiendo que 3x3 es lo más pedorro que existe, podrías asegurar que un box costará aproximadamente, no se, dos rays (?) , habría que profilear bien esto pero segun los resultados es más o menos así, quizás tendría que probar con 2x2 a ver que sale :)

 

 

 

Share this post


Link to post
Share on other sites

eso de 1 box = 2 rays esta muy bien...

gracias por la info

si, esta claro que un box va mejor para alguna cosas...:91_thumbsup: habria que estudiar un poco cada caso...

si haces el test pon el resultado que me gustaria verlo;) 

mirare a ver si puedo cambiar el script para usar los Box... porque los rays que lanzo, aparte de que estan colocados estrategicamente, los uso para calcular miVelocity y miTorque (del vehiculo) ...y con el box tendre que variar un poco ese metodo ya que no van a ser varios rallos, sino un unico box... 

el boxCast usa el "out hit" ?

( RaycastHit hit; )?

Share this post


Link to post
Share on other sites
1 hour ago, Igor said:

el boxCast usa el "out hit" ?

( RaycastHit hit; )?

Sí :

En 2D

RayCastHit2D hitInfo = Physics2D.Boxcast( ....

En 3D

bool hit = Physics.Boxcast( .... , out hitInfo , ...)

personalmente prefiero la notación del 2D, a tener en cuenta es que el size en 2D es el completo, en 3D son los extents (size/2)... el ángulo en 2D es un float, en 3D un quaternion, el resto es igual

 

Edited by lightbug

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...