CHIPMUNK en bennu

[josebita]

Acabo de probar la mod_chipmunk de mi PPA y parece que va bastante bien; incluso la simulación del agua funciona a bastante buen ritmo en mi portátil :)

[Erkosone]

Supongo que estás en linux, podrías probar si el ultimo ejemplo que acompaña el API que he colgado funciona correctamente en linux?
Supongo que si, pero tengo curiosidad ya por asegurarme.


Bueno.. si tienes tiempo  ;D

[josebita]

Supongo que estás en linux, podrías probar si el ultimo ejemplo que acompaña el API que he colgado funciona correctamente en linux?
Supongo que si, pero tengo curiosidad ya por asegurarme.


Bueno.. si tienes tiempo  ;D

Si es el test20, aquí lo tienes:
http://www.youtube.com/watch?v=ClauPLL1ba0&feature=youtu.be

He grabado el vídeo con lo primero que tenía a mano (VLC) y se ve un poco raro, pero en vivo va muy bien.

[Prg]

Acabo de probar la mod_chipmunk de mi PPA y parece que va bastante bien; incluso la simulación del agua funciona a bastante buen ritmo en mi portátil :)

El problema del agua es el pintado.
El algoritmo de simulación se basa en partículas bajo el sistema SPH y es rápido, pero el pintado usa una función de cálculo de campo eléctrico y es muy caro. Hay métodos de aceleración de este algoritmo (aseguran acelerarlo 200 veces), pero lo intenté programar y a mí no me funcionó; no tenía mucho tiempo de programarlo así que no revisé que todo estuviera bien...

Está en pruebas y todavía no esá listo para usarse...

Me alegro que funcione todo bien en linux... Excelentes noticias. Gracias por compilarlo y probarlo.

[josebita]

Me alegro que funcione todo bien en linux... Excelentes noticias. Gracias por compilarlo y probarlo.

Nada, según vayas subiendo versiones nuevas de la mod_chipmunk las iré subiendo a mi PPA. Creo que la librería es tremendamente interesante y merece la pena el trabajo para que la gente la pueda usar de forma cómoda.

[SplinterGU]

no habia visto tu video nuevo... pregunto, por que la gravedad a 500? no se puede poner la gravedad en valores realistas? por ejemplo, 9,78 mt/s y se comportaria como la gravedad de la tierra?
por otro lado, la pelota veo que no se mueve mucho? como se calcula la masa de un cuerpo? la pones tu? porque o la pelota tiene mucha masa o la catapulta poco peso...

la prueba esta genial, pero no lo veo muy realista... me hace dudar esto sobre la chipmunk.

[Erkosone]

No dudes de la lib Splinter ;)


Las masas las pone el usuario por que es un valor que no se puede automatizar, ya que proviene del tipo de material, la densidad del mismo y la estructura molecular del propio material, un objeto de "hierro" no tiene la misma masa que un objeto de forma exactamente igual pero de "espuma" o de "paja".


Todo depende de la aproximación que haga el usuario sobre la masa "y su centro de gravedad" a un objeto cualquiera, con diferentes valores de masa se pueden apreciar comportamientos en la simulación completamente distintos.


Normalmente solemos usar valores de masa al tun tun así a la brava o por aproximación de "lo que a nosotros nos parece correcto.


Existen varias formulas de física clásica que pueden calcular una aproximación muy exacta sobre el "AREA" de un polígono, pero la cosa no es tan simple.. pues con un CG "centro de gravedad" mal ubicado produce efectos muy adversos en el objeto y es casi inutil su uso.




Para las figuras geométricas regulares si que se puede crear una función que devuelva un valor de masa bastante correcto, la función debería calcular el "AREA" de la figura y aplicar una simple multiplicación dependiendo de la densidad molecular del material del que desea que devuelva el valor de masa..


Un ejemplo:


Shape: TYPE_BOX
Sprite Size: 50x50 pixel.
Area = width * heigth;
Mass = Area * molecularDensity_;


Donde la variable molecularDensity_ adopta por ejemplo los siguientes valores prefabricados:
ACERO_ = 0.98;
HIERRO_ = 0.90;
PIEDRA_ = 0.83;
PLASTICO_ = 0.72;
MADERA_ = 0.76;
ESPUMA_ = 0.30;
LOW_DENSITY_MATERIAL_ = 0.11;


Entonces tenemos que la función resultante para un calculo aproximado de la masa de un objeto en la simulación podría ser esta:


function Get_Shape_Mass( file, graph, int material_ );
begin
ancho = map_info(file,graph,g_width);
alto = map_info(file,graph,g_heigth);
area = ancho * alto;
masa = area * material_;
return(masa);
end


Si se crea una tabla de calidad se podría hasta añadir a la mod_chipmunk XD.. esto facilitaría todavía mas si cabe su uso, casi que estoy por añadirlo a la PhysicsMotionAPI  ;D

[Prg]

no habia visto tu video nuevo... pregunto, por que la gravedad a 500? no se puede poner la gravedad en valores realistas? por ejemplo, 9,78 mt/s y se comportaria como la gravedad de la tierra?
por otro lado, la pelota veo que no se mueve mucho? como se calcula la masa de un cuerpo? la pones tu? porque o la pelota tiene mucha masa o la catapulta poco peso...

la prueba esta genial, pero no lo veo muy realista... me hace dudar esto sobre la chipmunk.

La masa la defino yo. Le di 30 kg a la pelota y 1 kg al bloque.
La fuerza de los resortes de la  catapulta también los puse yo.

Lo que pasa es que depende de cúanto mide un pixel en la realidad. En mi caso si digo que un pixel mide 1.962cm, la gravedad que uso es de  9.81 m/s^2

Cada bloque mide 40 pixeles de longitud, así que en la realidad medirían:
40px*1.962cm=78.48 cm
500px*1.962cm=981 cm -> 9.81 m

Aunque los bloques están grandes y su peso es poco, imaginemos un material similar al hielo seco, un poco más pesado...

[SplinterGU]

No dudes de la lib Splinter ;)


Las masas las pone el usuario por que es un valor que no se puede automatizar, ya que proviene del tipo de material, la densidad del mismo y la estructura molecular del propio material, un objeto de "hierro" no tiene la misma masa que un objeto de forma exactamente igual pero de "espuma" o de "paja".


Todo depende de la aproximación que haga el usuario sobre la masa "y su centro de gravedad" a un objeto cualquiera, con diferentes valores de masa se pueden apreciar comportamientos en la simulación completamente distintos.


Normalmente solemos usar valores de masa al tun tun así a la brava o por aproximación de "lo que a nosotros nos parece correcto.


Existen varias formulas de física clásica que pueden calcular una aproximación muy exacta sobre el "AREA" de un polígono, pero la cosa no es tan simple.. pues con un CG "centro de gravedad" mal ubicado produce efectos muy adversos en el objeto y es casi inutil su uso.




Para las figuras geométricas regulares si que se puede crear una función que devuelva un valor de masa bastante correcto, la función debería calcular el "AREA" de la figura y aplicar una simple multiplicación dependiendo de la densidad molecular del material del que desea que devuelva el valor de masa..


Un ejemplo:


Shape: TYPE_BOX
Sprite Size: 50x50 pixel.
Area = width * heigth;
Mass = Area * molecularDensity_;


Donde la variable molecularDensity_ adopta por ejemplo los siguientes valores prefabricados:
ACERO_ = 0.98;
HIERRO_ = 0.90;
PIEDRA_ = 0.83;
PLASTICO_ = 0.72;
MADERA_ = 0.76;
ESPUMA_ = 0.30;
LOW_DENSITY_MATERIAL_ = 0.11;


Entonces tenemos que la función resultante para un calculo aproximado de la masa de un objeto en la simulación podría ser esta:


function Get_Shape_Mass( file, graph, int material_ );
begin
ancho = map_info(file,graph,g_width);
alto = map_info(file,graph,g_heigth);
area = ancho * alto;
masa = area * material_;
return(masa);
end


Si se crea una tabla de calidad se podría hasta añadir a la mod_chipmunk XD.. esto facilitaría todavía mas si cabe su uso, casi que estoy por añadirlo a la PhysicsMotionAPI  ;D

me imagine que no era automatico, pero como en algun momento me parecio leer algun comentario que hablaba de valores automaticos creo que para esto, pregunte, pero quizas me parecio y no fue asi.

por otro lado, esa iba a ser mi sugerencia, tener una variable local que defina el tipo de material.

no habia visto tu video nuevo... pregunto, por que la gravedad a 500? no se puede poner la gravedad en valores realistas? por ejemplo, 9,78 mt/s y se comportaria como la gravedad de la tierra?
por otro lado, la pelota veo que no se mueve mucho? como se calcula la masa de un cuerpo? la pones tu? porque o la pelota tiene mucha masa o la catapulta poco peso...

la prueba esta genial, pero no lo veo muy realista... me hace dudar esto sobre la chipmunk.

La masa la defino yo. Le di 30 kg a la pelota y 1 kg al bloque.
La fuerza de los resortes de la  catapulta también los puse yo.

Lo que pasa es que depende de cúanto mide un pixel en la realidad. En mi caso si digo que un pixel mide 1.962cm, la gravedad que uso es de  9.81 m/s^2

Cada bloque mide 40 pixeles de longitud, así que en la realidad medirían:
40px*1.962cm=78.48 cm
500px*1.962cm=981 cm -> 9.81 m

Aunque los bloques están grandes y su peso es poco, imaginemos un material similar al hielo seco, un poco más pesado...

ahi si que la complicaste o la chipmunk la veo super compleja... vamos, yo pongo gravedad del entorno 9.81, y masa de mi cuerpo N, y la chipmunk deberia hacer el resto, no me parece logico ni facil tener que estar calculando en base al tamaño y demas, cual es la gracia de la chipmunk si no puede hacer eso? bueno, quizas yo lo estoy viendo desde un punto de vista equivocado.

[Prg]

No dudes de la lib Splinter ;)


Las masas las pone el usuario por que es un valor que no se puede automatizar, ya que proviene del tipo de material, la densidad del mismo y la estructura molecular del propio material, un objeto de "hierro" no tiene la misma masa que un objeto de forma exactamente igual pero de "espuma" o de "paja".


Todo depende de la aproximación que haga el usuario sobre la masa "y su centro de gravedad" a un objeto cualquiera, con diferentes valores de masa se pueden apreciar comportamientos en la simulación completamente distintos.


Normalmente solemos usar valores de masa al tun tun así a la brava o por aproximación de "lo que a nosotros nos parece correcto.


Existen varias formulas de física clásica que pueden calcular una aproximación muy exacta sobre el "AREA" de un polígono, pero la cosa no es tan simple.. pues con un CG "centro de gravedad" mal ubicado produce efectos muy adversos en el objeto y es casi inutil su uso.




Para las figuras geométricas regulares si que se puede crear una función que devuelva un valor de masa bastante correcto, la función debería calcular el "AREA" de la figura y aplicar una simple multiplicación dependiendo de la densidad molecular del material del que desea que devuelva el valor de masa..


Un ejemplo:


Shape: TYPE_BOX
Sprite Size: 50x50 pixel.
Area = width * heigth;
Mass = Area * molecularDensity_;


Donde la variable molecularDensity_ adopta por ejemplo los siguientes valores prefabricados:
ACERO_ = 0.98;
HIERRO_ = 0.90;
PIEDRA_ = 0.83;
PLASTICO_ = 0.72;
MADERA_ = 0.76;
ESPUMA_ = 0.30;
LOW_DENSITY_MATERIAL_ = 0.11;


Entonces tenemos que la función resultante para un calculo aproximado de la masa de un objeto en la simulación podría ser esta:


function Get_Shape_Mass( file, graph, int material_ );
begin
ancho = map_info(file,graph,g_width);
alto = map_info(file,graph,g_heigth);
area = ancho * alto;
masa = area * material_;
return(masa);
end


Si se crea una tabla de calidad se podría hasta añadir a la mod_chipmunk XD.. esto facilitaría todavía mas si cabe su uso, casi que estoy por añadirlo a la PhysicsMotionAPI  ;D

me imagine que no era automatico, pero como en algun momento me parecio leer algun comentario que hablaba de valores automaticos creo que para esto, pregunte, pero quizas me parecio y no fue asi.

por otro lado, esa iba a ser mi sugerencia, tener una variable local que defina el tipo de material.

no habia visto tu video nuevo... pregunto, por que la gravedad a 500? no se puede poner la gravedad en valores realistas? por ejemplo, 9,78 mt/s y se comportaria como la gravedad de la tierra?
por otro lado, la pelota veo que no se mueve mucho? como se calcula la masa de un cuerpo? la pones tu? porque o la pelota tiene mucha masa o la catapulta poco peso...

la prueba esta genial, pero no lo veo muy realista... me hace dudar esto sobre la chipmunk.

La masa la defino yo. Le di 30 kg a la pelota y 1 kg al bloque.
La fuerza de los resortes de la  catapulta también los puse yo.

Lo que pasa es que depende de cúanto mide un pixel en la realidad. En mi caso si digo que un pixel mide 1.962cm, la gravedad que uso es de  9.81 m/s^2

Cada bloque mide 40 pixeles de longitud, así que en la realidad medirían:
40px*1.962cm=78.48 cm
500px*1.962cm=981 cm -> 9.81 m

Aunque los bloques están grandes y su peso es poco, imaginemos un material similar al hielo seco, un poco más pesado...

ahi si que la complicaste o la chipmunk la veo super compleja... vamos, yo pongo gravedad del entorno 9.81, y masa de mi cuerpo N, y la chipmunk deberia hacer el resto, no me parece logico ni facil tener que estar calculando en base al tamaño y demas, cual es la gracia de la chipmunk si no puede hacer eso? bueno, quizas yo lo estoy viendo desde un punto de vista equivocado.

Es que el mundo real y el dibujado siempre llevan una escala. 1 m no es igual a 1 pixel.

Si en la gravedad pongo 9.81, ella entiende que debe mover 9.81 pixeles por segundo como aceleración. Si así fuera los objetos de menos de 1 m no se podrían dibujar (Serían menos de un pixel). Nuestros cálculos siempre deben llevar el factor de escala, a menos que hagamos coincidir un metro con 1 pixel.

[josebita]

También piensa, Splinter, que la librería está hecha para cosas más juegos con físicas complejas. No tiene mucho sentido utilizar una librería como ésta en caso de que tu juego sea muy simple pero si quieres utilizar físicas complejas la librería te ayuda.

Un ejemplo: un coche de carreras en el aire un coche que se comporte de manera realista mantendrá el momento cinético del conjunto ruedas+cuerpo encabritando o picando cuando el jugador frene las ruedas o las acelere. Cuando uno quiere ocuparse de esas sutilezas, empieza a ser importante que una librería como ésta te ayude.

Yo el tema de ajustes las propiedades físicas lo veo un poco como ajustar músicas/gráficos en un juego: se puede hacer que el juego funcione con cualquier cosa que se tenga a mano pero si si quiere que el juego sea realmente vistoso hay que dedicarle un tiempo a pensarlo todo.

[Prg]

En otro hilo hablamos de los cuerpos que Chipmunk podía generar. Hablaré un poco al respecto.

Cuando asignamos a un proces un gráfico, le podemos pedir que le asigne un cuerpo a éste; lo podemos generar manualmente mediante una lista de parámetros usando una variable del proceso y un arreglo o podemos usar unas funciones que agregan estos cuerpos al proceso (son 3 métodos).

Si le pedimos que lo genere manualmente la librería puede generar los siguientes cuerpos:

Círculos
Toma el ancho y el alto y los promedia, ese será el diámetro.
El centro lo hace así:

cx=-(px-(map->width/ 2))*c;
cy=-(py-(map->height/2))*c;

con px y py las coordenadas del punto de control 0 y c el factor de escala del gráfico normalizado.

        if ( map->ncpoints > 0 )
        {
            if ( map->cpoints[0].x != CPOINT_UNDEFINED ){
                px= map->cpoints[0].x ;
            }else{
                px= map->width / 2 ;
            }
            if ( map->cpoints[0].y != CPOINT_UNDEFINED ){
                py= map->cpoints[0].y ;
            }else{
                py= map->height / 2 ;
            }
        }
        else
        {
            px= map->width / 2 ;
            py= map->height / 2 ;

        }

Vacío
Si tenemos un cuerpo vacío no hace nada. Útil para el ratón, que no debe mover objetos al colisionar con ellos.

Caja
Genera un rectángulo con las dimensiones del gráfico

Linea
Calcula la longitud de la linea (el ancho si mide más al alto, de lo contrario el alto)
calcula el grosor (la otra magnitud)
Y genera una linea de bordes circulares desde los extremos
Actualmente los bordes circulares quedan fuera del gráfico, por tal motivo si se requieren lineas gruesas es mejor usar cajas.

Cuerpos convexos
Procesa el gráfico y le ajusta un cuerpo convexo. Triángulos, cuadros, pentágonos, hexágonos, ... ,polígonos regulares y polígonos irregulares convexos.
Uno a todo el gráfico.

Son todos los cuerpos que la librería detecta automáticamente para los procesos, sin embargo existe una nueva característica:

Aproximaciones poligonales. (Test 18)

La función es:

mundo=generateAproxPoly(0,terreno,umbral); //file,graph,umbral de tolerancia

Esta función retorna una lista con listas de puntos a partir de un gráfico y un umbral.

Cada lista que forma a la lista principal es un objeto detectado en el gráfico o un hueco. A partir de estas listas se pueden generar procesos con la forma detectada y dormirlos para hacer objetos físicos que caen al tocarlos o cosas así (requeriría más procesmaiento a las listas).

También se puede hacer el mundo, el scroll, el screen. Esto es lo que hace el video. El código requerido para hacer esto está en el test antes mensionado y es muy sencillo.

Code Select Expand

function pLinea(cpVect * c1,cpVect *c2)
begin
  draw_line(c1.x,c1.y,c2.x,c2.y);
  z=addInanimateShape(type_line, c1.x,c1.y,c2.x,c2.y, 1);
  DefShapeI(z,CP_C_LAYERS,NOT_GRABABLE_MASK);
     
end

function genTerr(int l)
private
    cantL, cantP,objeto,i;
    cpVect * c1;
    cpVect * c2;
    int ln;
begin
       cantL=cantElement(l);
       for (z=0;z<cantL;z++)
           objeto=getElement(l,z);
           cantP=cantElement(objeto);
             for (i=0;i<cantP-1;i++)
                  c1=getElement(objeto,i);
                  c2=getElement(objeto,i+1);
                 pLinea(c1,c2);
                 ln++;
                 draw_fcircle(c1.x,c1.y,4);
             end
             draw_fcircle(c2.x,c2.y,4);
       end
       say("lineas generadas = "+ ++ln);
end

solo se le pasa la lista que retorna la función.
Espero en un futuro hacer una función que ya haga el terreno (actualmente sólo nos retorna la lista de puntos, pero poco falta para hacerlo), y otra que permita modificar la lista, pasándole un recuadro de la parte modificada del gráfico (las coordenadas de las esquinas del recuadro en el gráfico).

Por qué decidí que retornara la lista ya. Porque es mucho más flexible, nos da mayores posibilidades.
Además se almacena en memoria para no calcularlo cada vez.

También se puede generar la aproximación y asignar cada una de las lineas al cuerpo de un proceso con las siguientes funciones
{"ADDCIRCLESHAPE" , "FFF",   TYPE_INT, modaddCircleShape},
    {"ADDSEGMENTSHAPE" , "FFFFF",   TYPE_INT, modaddSegmentShape},
    {"ADDPOLYSHAPE" , "FFIP",   TYPE_INT, modaddPolyShape},

ADDCIRCLESHAPE(x,y,radio)
ADDSEGMENTSHAPE(x1,y1,x2,y2,radio) //radio=grosor/2
ADDPOLYSHAPE(x,y,c,p) //c=cantidad de puntos p=puntero a lista de puntos

La x,y es el desplazamiento que se le aplicará a las coordenadas o el radio para ajustarlo al punto de control 0

Cuando ya no se use la aproximacion (las listas), se pueden borrar con la funcion deleteAproxPoly(mundo);

Con lo anterior concluimos que aunque no se calcula automáticamente el cuerpo cóncavo, se puede calcular de forma más o menos sencilla. Una vez calculado se almacena y luego se usa en cada proceso que lo requiera, sin necesidad de volver a calcular la aproximación poligonal.

El segundo método que es usando una lista de parámetros para la creación lo comentaré posteriormente, su funcionamiento se puede ver en el test03

[SplinterGU]

No dudes de la lib Splinter ;)


Las masas las pone el usuario por que es un valor que no se puede automatizar, ya que proviene del tipo de material, la densidad del mismo y la estructura molecular del propio material, un objeto de "hierro" no tiene la misma masa que un objeto de forma exactamente igual pero de "espuma" o de "paja".


Todo depende de la aproximación que haga el usuario sobre la masa "y su centro de gravedad" a un objeto cualquiera, con diferentes valores de masa se pueden apreciar comportamientos en la simulación completamente distintos.


Normalmente solemos usar valores de masa al tun tun así a la brava o por aproximación de "lo que a nosotros nos parece correcto.


Existen varias formulas de física clásica que pueden calcular una aproximación muy exacta sobre el "AREA" de un polígono, pero la cosa no es tan simple.. pues con un CG "centro de gravedad" mal ubicado produce efectos muy adversos en el objeto y es casi inutil su uso.




Para las figuras geométricas regulares si que se puede crear una función que devuelva un valor de masa bastante correcto, la función debería calcular el "AREA" de la figura y aplicar una simple multiplicación dependiendo de la densidad molecular del material del que desea que devuelva el valor de masa..


Un ejemplo:


Shape: TYPE_BOX
Sprite Size: 50x50 pixel.
Area = width * heigth;
Mass = Area * molecularDensity_;


Donde la variable molecularDensity_ adopta por ejemplo los siguientes valores prefabricados:
ACERO_ = 0.98;
HIERRO_ = 0.90;
PIEDRA_ = 0.83;
PLASTICO_ = 0.72;
MADERA_ = 0.76;
ESPUMA_ = 0.30;
LOW_DENSITY_MATERIAL_ = 0.11;


Entonces tenemos que la función resultante para un calculo aproximado de la masa de un objeto en la simulación podría ser esta:


function Get_Shape_Mass( file, graph, int material_ );
begin
ancho = map_info(file,graph,g_width);
alto = map_info(file,graph,g_heigth);
area = ancho * alto;
masa = area * material_;
return(masa);
end


Si se crea una tabla de calidad se podría hasta añadir a la mod_chipmunk XD.. esto facilitaría todavía mas si cabe su uso, casi que estoy por añadirlo a la PhysicsMotionAPI  ;D

me imagine que no era automatico, pero como en algun momento me parecio leer algun comentario que hablaba de valores automaticos creo que para esto, pregunte, pero quizas me parecio y no fue asi.

por otro lado, esa iba a ser mi sugerencia, tener una variable local que defina el tipo de material.

no habia visto tu video nuevo... pregunto, por que la gravedad a 500? no se puede poner la gravedad en valores realistas? por ejemplo, 9,78 mt/s y se comportaria como la gravedad de la tierra?
por otro lado, la pelota veo que no se mueve mucho? como se calcula la masa de un cuerpo? la pones tu? porque o la pelota tiene mucha masa o la catapulta poco peso...

la prueba esta genial, pero no lo veo muy realista... me hace dudar esto sobre la chipmunk.

La masa la defino yo. Le di 30 kg a la pelota y 1 kg al bloque.
La fuerza de los resortes de la  catapulta también los puse yo.

Lo que pasa es que depende de cúanto mide un pixel en la realidad. En mi caso si digo que un pixel mide 1.962cm, la gravedad que uso es de  9.81 m/s^2

Cada bloque mide 40 pixeles de longitud, así que en la realidad medirían:
40px*1.962cm=78.48 cm
500px*1.962cm=981 cm -> 9.81 m

Aunque los bloques están grandes y su peso es poco, imaginemos un material similar al hielo seco, un poco más pesado...

ahi si que la complicaste o la chipmunk la veo super compleja... vamos, yo pongo gravedad del entorno 9.81, y masa de mi cuerpo N, y la chipmunk deberia hacer el resto, no me parece logico ni facil tener que estar calculando en base al tamaño y demas, cual es la gracia de la chipmunk si no puede hacer eso? bueno, quizas yo lo estoy viendo desde un punto de vista equivocado.

Es que el mundo real y el dibujado siempre llevan una escala. 1 m no es igual a 1 pixel.

Si en la gravedad pongo 9.81, ella entiende que debe mover 9.81 pixeles por segundo como aceleración. Si así fuera los objetos de menos de 1 m no se podrían dibujar (Serían menos de un pixel). Nuestros cálculos siempre deben llevar el factor de escala, a menos que hagamos coincidir un metro con 1 pixel.

a mi me parece que la relacion pixels/distancia deberia ser abstraida en otra variable...

También piensa, Splinter, que la librería está hecha para cosas más juegos con físicas complejas. No tiene mucho sentido utilizar una librería como ésta en caso de que tu juego sea muy simple pero si quieres utilizar físicas complejas la librería te ayuda.

Un ejemplo: un coche de carreras en el aire un coche que se comporte de manera realista mantendrá el momento cinético del conjunto ruedas+cuerpo encabritando o picando cuando el jugador frene las ruedas o las acelere. Cuando uno quiere ocuparse de esas sutilezas, empieza a ser importante que una librería como ésta te ayude.

Yo el tema de ajustes las propiedades físicas lo veo un poco como ajustar músicas/gráficos en un juego: se puede hacer que el juego funcione con cualquier cosa que se tenga a mano pero si si quiere que el juego sea realmente vistoso hay que dedicarle un tiempo a pensarlo todo.

sigo sin ver la practicidad de este argumento...

creo que deberia ser mas simple, defino cuerpos, con su masa, entorno con su gravedad, defino relacion pixel/distancia, y aplico fuerzas... y todo en parametros realisticos... si tengo que poner 500 para decir 9.8, pues no es algo realista... y un motor de fisica entiendo que la idea es ser realista, sino para que la fisica? lo curramos por codigo y listo.

[SplinterGU]

gracias prg por la explicacion, muy buena...

con respecto a lo que yo decia... quizas lo dije mal.. :)

estaria bueno incluir lo que dije, y meter estas cosas, asi podemos trabajar con valores realistas y que el motor calcule a sus valores internos, con esto me refiero relacion pixel/distancia, gravedad, etc.

[Erkosone]

Lo que Josebita quiere decir en realidad es lo mismo que dice Prg Splinter y lo mismo que pienso yo también, basicamente es esto:


Vale, partimos de la base en que la gravedad es '9.8f' bien.. pero..


Para una resolución de 320x200 esa gravedad es muy alta.. sinembargo para una resolución full HD es quizá demasiado pequeña.. por que? justo por lo que explica Prg, por que la gravedad es una aceleración, y tu lo estás planteando desde el punto de vista de un espectador con visión "global", pero si lo miras desde una ventana la cosa cambia..  que ventana?? la pantalla de un dispositivo ya sea un PC, un mac.. un mobile..


Si la ventana es muy chica lo que vas a ver es un objeto callendo a una velocidad elevadísima.. pero si lo ves desde una ventana muy grande "con mas campo de visión" lo vas a ver mucho mas lento.. por que? por que tu como espectador tienes consciencia de que el entorno es muchisimo mas amplio y en consecuencia el feelig que recibes es como de mayor suavidad y menor velocidad, aunque realmente sea la misma gravedad.


Esto si se piensa detenidamente y se practica un poco es muy sencillo de evidenciarlo en un juego o en cualquier tipo de simulación física realista computerizada, mira:


Pantalla de 320x200, aplicamos física.. aplicamos gravedad de 9.8f.. vale.. los objetos caen a la velocidad del rayo.. por que? por que no vemos mas allá de una zona muy reducida del mundo.. en consecuencia tenemos que vajar todas las velocidades para que el juego fluya mas lento.. y todo se complica por este motivo..


Ahora nos ponemos a programar lo mismo para otra resolución.. por ejemplo de 1080p, vale.. aplicamos física.. aplicamos gravedad de 9.8f.. que leches?? ahora los objetos caen lentos.. no, caen a la misma velocidad.. pero tu como espectador eres consciente de que el espacio es mayor.. y en consecuencia recibes un feeling completamente distorsionado del anterior..


Conclusión?
Simplemente un buen motor de física debe ser completamente customizable, es cierto que cuanto mas abstraiga de calculos complejos mejor que mejor.. pero el programador ha de ser consciente en todo momento de lo que quiere presentar en pantalla.. y de cual es el feeling que quiere transmitir..
Por esto un motor de física no puede abstraer nunca de los jamases de algo tan importante como es la gravedad, por que aunque parezca raro.. la gravedad va fuertemente ligada a todos los calculos del engine.. ya que es una aceleración que ha de sumarse en todos los calculos justo antes de comenzarlos, y en consecuencia afectará de forma directa a los resultados.


Supongo que después de esta chapa ya ves la cosa desde otro punto de vista, puedes setear la gravedad a 9.8f y crear todo lo que quieras con valores reales de masa y bla bla bla.. en cuanto cambies de resolución has perdido lo que a los que nos apasiona la física llamamos "momentum", osea.. que el juego cambia radicalmente.