Apricot the open game project

[Caronte]

Eh, esto está bien.

Vaya, ya era hora.

[Leander]

Si hace 1 semana que esta hombres.
[Bf-blender-cvs] SVN commit: /data/svn/Bf-blender [15335] trunk/blender: BGE patch: add nand, Nor, XOR, xnor controllers..

[jedihe]

Vaya, un detalle: esta descripción esta rara, ¿verdad? Xnor controller is an inverted XOR: the output is 0 if and only.

If one input is 0 and all the other imputs are 0.

[Leander]

Vaya, un detalle: esta descripción esta rara, ¿verdad? Xnor controller is an inverted XOR: the output is 0 if and only.

If one input is 0 and all the other imputs are 0.

Es que en realidad es un nxor o sea un XOR invertido.

Edito: espera, no lo tengo claro si primero aplica un not a los imputs y luego el XOR, o es lo que dije al principio.

[Notxor]

Justo eso es not XOR. Un abrazo.

[jedihe]

One input is 0 and all the other imputs are 0. Eso es lo raro. Jedihe.

[Caronte]

Creo que eso se debe a que las operación lógicas del game-engine aceptan comparaciones múltiples, en lugar de hacer la operación entre 2 operandos, como es el caso habitual en programación (que me corrija Notxor si me equivoco).

[Mataii]

Intente publicar en el foro de Apricot unas observaciones que hice del modelo de Frank, pero no he podido poner mi comentario por, allá, no sé porque.

Así que las dejare por aquí, ya que hay varios interesados en el tema, a ver si alguno coincide con mis observaciones.

Esta escrito con mi inglés mocho, porque estaría en el blog de Apricot, así que, lo pongo tal cual.

Well, y got the Frank blend and i made a Little review/crit of it instead an animation.

I loked the wireframe model of Frank and the first i noticed is some triangulation (or fans, Fanning) in geometry and well, y think it should be fixed. http://salvador.mata.com.mx/aprico/f...ngulations.jpg.

So i decided todo make some kind of proposal, y take the model and correct it (according my point of view and my experience), the first i get.
Was some lacking of Symmetry in the model and an example can be found in the enlace below: http://salvador.mata.com.mx/Apricot/frank_simmetry.jpg.

And the hands, y get diferent poly count in both hands, and i think it has todo Many Polygons. http://salvador.mata.com.mx/Apricot/frank_hands.jpg.

The ears of Frank, again i think they have more Polygons than neded, Frank is a small character and dont ned that level of detail. If Normal Maps are going todo be used then the Normal Map should do their work: simulate geometry. http://salvador.mata.com.mx/Apricot/frank_ears.jpg.

Frank fot, again i think it has todo Many Polygons (271 tris). http://salvador.mata.com.mx/Apricot/frank_tomany.jpg.

Frank mouth. http://salvador.mata.com.mx/Apricot/frank_mouth.jpg.

And the uvsets maybe should be more optimized todo get most of the área covered by the surface object.

The Normal Map looks so flat, diferent than i get from the bake (hi->low), can be found in the blend.

And here the original Frank and the modified one (from me), and of course i have todo remove every shape key. http://salvador.mata.com.mx/Apricot/..._optimized.jpg. http://salvador.mata.com.mx/Apricot/..._optimized.jpg. http://salvador.mata.com.mx/Apricot/frank_opt.jpg. http://salvador.mata.com.mx/Apricot/frank_optimized.jpg. http://salvador.mata.com.mx/Apricot/frank_prop.jpg.

Here the blend (lo siento for the file size). http://salvador.mata.com.mx/Apricot/frank_mod.rar.
Well this is only a suggestion, y know that Apricot Will re-use Peach models for fast development but i think they should be modified or adapted todo video games, y think if the models are optimized the game Will work Even better on more PC systems.

And god work, animations looks very god.

[venomgfx]

Hey Matai, ahora estoy descuartizando tu modelo, gracias a tus screenshots y cambios logre cambiar la schedule para esta semana y así invertir el día de hoy (cada día cuenta y mucho) en el personaje, para luego seguir el resto de la semana en el nuevo nivel que estamos preparando. Gracias otra vez mata.

Por cierto, el tema que no aparecía tu comentario es que, al poner tantos links, el Wordpress lo toma como spam, por ende entra en moderación, y hasta que alguno de nosotros no entre al administrador del blog y lo apruebe el comentario queda ahí sin aparecer.

[Mataii]

Hey Matai, ahora estoy descuartizando tu modelo, gracias a tus screenshots y cambios logre cambiar la schedule para esta semana y así invertir el día de hoy (cada día cuenta y mucho) en el personaje, para luego seguir el resto de la semana en el nuevo nivel que estamos preparando. Gracias otra vez mata.

Por cierto, el tema que no aparecía tu comentario es que, al poner tantos links, el Wordpress lo toma como spam, por ende entra en moderación, y hasta que alguno de nosotros no entre al administrador del blog y lo apruebe el comentario queda ahí sin aparecer.

Hey Venom, que tal, en primer lugar gracias a ustedes, en primera por el trabajo que están haciendo, que reconozco que es una labor faraonica que requiere de mucho esfuerzo y que sin duda no cualquiera puede con eso y también por tener esa oportunidad de aportar con algo al proyecto, quise intentar hacer una animación, pero al final pensé que tenía que comentar lo que pensaba que podría mejorarse un poco.

Y sí, justo en la noche estuve pensando que probablemente mi mensaje estaría en moderación debido a la cantidad de enlaces que tenía, una disculpa si me vi un poco impaciente con eso.

Y pues nada más, seguiremos al pendiente saludos a todos por, allá.

[jedihe]

(Leander, Notxor y Caronte): Vamos por pasos:
1. A XOR b = 1, cuando una y sólo una entrada vale 1. La generalización a más entradas es intuitiva.
2. Not(a XOR b) = 0, cuando a XOR b = 1. La razón por la que creo que está raro es que me parece que el enunciado correcto es: xnor = 0 cuando una y sólo una de las entradas vale 1 y el resto vale 0.

Adicionalmente, no tiene mucho sentido gastarse el tiempo de escribir: una entrada vale 0 y el resto de las entradas vale 0, cuando eso es igual a decir: todas las entradas valen 0.

Alguien de acuerdo?
@Matai: no puedo acceder a las imágenes, me aparece un error 403 - Forbidden.

[Caronte]

Adicionalmente, no tiene mucho sentido gastarse el tiempo de escribir: una entrada vale 0 y el resto de las entradas vale 0, cuando eso es igual a decir: todas las entradas valen 0.

Pues sí, podría ser un error de copy/paste que se olvidaron corregir.

[Klópes]

En XOR, cada entrada 1 cambia el valor, así que, los 1s se anulan de dos en dos:
0 XOR 0 = 1 XOR 1 = 0. Así que, en una operación podemos simplificar todos los 0s, y a los 1s por parejas. Al final nos puede quedar 1, o nada (en cuyo caso el resultado es 0).

Así que, para XOR, la definición sería es 1 si y sólo si el número de unos es impar.

Para nxor sería, por tanto, es 0 si y sólo si el número de unos es impar.

Sí, esa definición estaba bastante mal.

[Leander]

Ya tenéis demo jugable. Apricot blog archive first playable demo..

[Klópes]

Ahora el actuador motion tiene opción de servocontrol. Me ha constado pillar lo que es, pero veo que es una opción que hacía mucha falta. Sirve más o menos para dirigir un objeto a golpes, pero usando velocidad lineal en vez de fuerza. Se basa en la capacidad de los motores servo para llevar los engranajes hasta una posición determinada y parar entonces.

Venom, ¿se puede saber que estáis montando?

-- IMÁGENES ADJUNTAS --

[jedihe]

Excelente, algo así andaba buscando hace un mes. Jedihe.

[SamCameron]

Yo echo de menos un actuador como este: actuador for global position? - Blender artists forums.

Creo que no debe ser difícil de programar y ahorraría mucho tiempo con una función muy habitual en la programación de juegos como es la posición global al presionar un determinado botón o al cambiar alguna propiedad de un objeto, ojalá alguien lo implemente porque estoy seguro que no es nada difícil.

[lordloki]

Hombre, ese actuador es sencillo de programar, pero más sencillo aún es utilizar el ejemplo en Python que te han puesto.

Yo creo que habría que diferenciar entre necesidades genéricas (que se necesiten en casi todos los juegos) para las que si se tendría que desarrollar un actuador y necesidades muy especificas que se tendrían que cubrir a base de programar en Python como en este caso.

De todas formas, si se quiere hacer un juego yo creo que algo de programación se tiene que aprender.

Pero vamos es solo mi opinión.

[SamCameron]

Lordloki entiendo tu opinión, lo que me sorprende es que nadie este a favor de un actuador como este, ya que en las veces que he utilizado otros engines (Darkbasic, Blitz,) siempre se ha necesitado un comando similar, vamos que es algo muy común, te pondré un ejemplo tonto, he estado probando el script y un método basado en Ipos, y creo que ninguno de ellos seria tan rápido como tener un actuador especifico para esto y simplemente conectarlo a un controlador, ahorrariamos un montón de tiempo y facilitariamos la tarea a los menos iniciados en Python o programación, vamos que veo más ventajas que inconvenientes, pero por lo que se ve soy el único que lo encuentra imprescindible, vamos que no entiendo que mal puede haber en tener una función tan común en todos los juegos de una manera tan cómoda como con un par de clicks.

[jedihe]

Samcameron: concuerdo en que para efectos de workflow es mucho más práctico tener la funcionalidad como actuador. No sabía que este tipo de actuador es común en otros entornos.

En lo personal, creo que este tipo de falencias se deba a que el desarrollo del ge había estado relativamente quieto durante buen tiempo, ahora que Apricot esta demandando avances, las cosas han cambiado.

[Cesar Saez]

Yo no tengo ni idea del ge o de la Api de Blender para Python, pero si lo haces por scripting simplemente haces un loop en tu selección y puedes cambiar todo de una vez de forma eficiente, rápida y limpia, de ahí los comentarios en blenderartists sobre que tan practico es hacerlo uno por uno mediante una interfaz vs scripting cuando necesitas setear varios objetos.

No le tengas miedo al código, te va a terminar gustando y todo. No tiene mucho sentido hacer trabajo repetitivo si le puedes indicar la lógica a la ordenador para que lo haga más rápido e incluso mejor, aprovecha tu tiempo concentrándote en lo importante.

[Klópes]

Samcameron: un actuador que sirve para llevar un objeto a una posición concreta. ¿a qué posición? Vale, que tenga una entrada x y, z. ¿para qué te sirve poner 3 valores concretos? La potencia de esa herramienta sería que pudieras mandar esos valores desde algo que los calcule, ¿no? Un script. Así que tenemos un script que llama (a un controlador que llama) a un actuador para darle unos valores que mandan a un objeto a una posición.
¿No es más cómodo que ese script mande al objeto directamente usando dos líneas?

[Pepius]

Exacto, esa sería la gracia, como, por ejemplo, poder introducir X,Y,Z como las coordenadas de otro objeto, o el punto medio entre dos, etc.

Por cierto, Klópes, puedes explicarme un poco más detalladamente eso del servocontrol? Un saludo.

[Klópes]

Por cierto, Klópes, puedes explicarme un poco más detalladamente eso del servocontrol? Un saludo.

Pues no. ¿a qué jode? Saltaplat:
Ya me gustaría, me pegué ayer toda la tarde con eso, y sólo conseguí ver la diferencia: con cierta configuración de valores, el objeto acelera hasta la velocidad de entrada, en vez de arrancar bruscamente. Puedes cambiar la aceleración, pero parece que se basa en otra cosa porque aparecen efectos de frenado y rebote, a ver si aparece Venom y nos lo cuenta.

[Klópes]

Por cierto, atención al constraint distance, que parece que tiene miga. Los objetos se dan la vuelta y rebotan, y se quedan a una distancia de la pared.

-- IMÁGENES ADJUNTAS --

[SamCameron]

Klopes, lo que tú dices de mandarle posiciones mediante script ya lo había pensado, y no necesitas necesariamente un script, puedes meterle datos mediante properties, además vosotros habláis de emplear este actuador en multitud de objetos y todo eso, pero yo las veces que lo he necesitado han sido para unos pocos objetos concretos o para movimiento pre-calculados, pero necesario es casi siempre, luego veo más rápido seleccionar el actuador y conectarlo que tener que ponerme a escribir código, podéis decir que os gusta más escribir código o que pierde la gracia o que el sol brilla en california, pero no podéis decir que sin este actuador podéis hacer lo mismo de forma tan rápido como serían un par de clicks, sobre todo para una tarea tan repetida y necesaria en cualquier desarrollo de un juego.

Posdata: no tengo miedo al código ya que he utilziado antes Darkbasic y Blitz como mencionaba, pero cuando descubrí Blender pensé que ya no necesitaría escribir código casi, parece que me equivocaba si la gente sigue pensando así.

[Caronte]

Sobre todo para una tarea tan repetida y necesaria en cualquier desarrollo de un juego.

¿puedes poner ejemplos? Es que no lo veo como algo muy usado.

[Klópes]

A ver. ¿me quieres decir de verdad que usando un actuador te va a salir más sencillo que esto?

-- IMÁGENES ADJUNTAS --

[SamCameron]

Si Klópes.

[Klópes]

Vaya, bueno, no sé qué decir. Quizá tengas razón y cuando lo implementen puedas decirnos cómo.

[Caronte]

Lo que el quiere decir, es que con su método tardaría 15 segundos y con el tuyo, tardas 30, lo cual es una barbaridad.

[Pepius]

Vale, es lícito admitir que eso sería mínimamente más rápido. Si aun así, admitiéramos que ese lapso de tiempo influiría en algo, aún esta la cuestión de que hay 1.000 cosas más importantes por hacer antes que eso. Un saludo.

[SamCameron]

No solo sería más rápido sino que para los no iniciados en programación también sería más amigable y a veces olvidas lo que tienes que poner, luego tienes que dedicar un tiempo a buscar los comandos, esto lo hace más sencillo si tenemos un actuador al alcance de la mano siempre que lo necesitemos para una tarea tan común como la que realiza, al fin y al cabo, no hablamos de un actuador tipo crear Tomb Raider o crear Doom 3 sino que es una herramienta muy ultilizada, por lo que cuanto más a mano mejor. Algo así seria.

-- IMÁGENES ADJUNTAS --

[Klópes]

Bien, pero haces algo de trampa. El uso de propiedades a ese nivel implicaría utilizarlas al completo en todo el engine. O sea, ¿ponemos un campo prop debajo de cada entrada numérica? No es descabellado, desde luego, pero habría que ver hasta qué punto es amigable un entorno así.

El ge está orientado a otra forma de trabajo, una mezcla entre ambos sistemas: bloques y código. Y tender a sustituir el código por logic bricks hace que un proyecto se complique innecesariamente. Digamos que en algún punto hay que cortar. Y creo que donde hoy se corta es el punto correcto. De hecho, la experiencia de Apricot es invalorable para esto.

Por último, un comentario sobre el método tuyo: para hacer lo que quieres has utilizado 3 propiedades. Sólo hay dos formas de modificarlas: por código y con el disparador property, que, por sí solo no puede hacer grandes cosas. Para algo tan sencillo como lo que dice Pepius (sacar el valor medio) necesitas código.

Creo que no te he convencido mucho, es un tema muy general y tendríamos que tirarnos ejemplos a la cabeza, pero yo lo tengo bastante claro: en su día también llegué a pensar que ese disparador debía existir, pero al ver lo sencillo que era hacerlo con líneas, y que para hacer un juego mínimamente serio hace falta programar mucho, vi que cuantos menos bloques, mejor. Un saludo.

[SamCameron]

Según la última entrada en el blog de Apricot, se han echado atrás y no van a ser lo que dijeron sino algo mucho más sencillo y limitado, vaya que lástima, ojalá alguien retome su trabajo.

[Mataii]

Según la última entrada en el blog de Apricot, se han echado atrás y no van a ser lo que dijeron sino algo mucho más sencillo y limitado, vaya que lástima, ojalá alguien retome su trabajo.

Creo que una cosa es echarse para atrás, y otra es ser claro y decir como están las cosas.

Tu mismo puedes retomar la parte que quieras, hacer un nuevo nivel, lo que se te antoje, ahí tienes todos los recursos que necesitas, contando con el más valioso y que hizo falta para el proyecto Apricot (tiempo).

[Klópes]

Últimamente he probado unas escenas en el ge y me quito el sombrero con las optimizaciones que ha hecho esta gente. Primero, una escena con algo menos de 200.000 polígonos, al pulsar p en la versión oficial, se quedaba extasiado durante aproximadamente, medio minuto (no recuerdo cuanto) antes de ejecutar el juego. En la compilación Apricot comenzaba al instante.

Ahora estoy con una escena donde hay unos árboles con hojas y sus clipmaps, al estilo del juego. Bien: en la versión oficial me da un rate máximo de 3 fps. En la compañero de Apricot (y también en la SVN) alcanza los 60 fps.

Realmente, parece que no le influyan los canales alfa.

Bravo.

[lordloki]

Están haciendo pruebas de rendimiento con distintas tarjetas. Si podéis poner vuestros resultados seguro que os lo agradecerán.

[Klópes]

Y documentación del GLSL. blender.org - Realtime GLSL materiales.

[Bluder]

Vaya funciona que da gusto, para pintar sobre el modelo te ahorra muchas pruebas.

[Klópes]

Qué silencioso esta esto. Ahí va el estado actual: Apricot Blender Game Engine work in progress 28/july on Vimeo.
(¿se pueden insertar los videos de Vimeo?).

Por cierto, el título es yo Frankie.

[Mataii]

Si, se ve que va progresando muy bien el proyecto ahora ya varios amigos tienen mejores opiniones al respecto. Saludos.

[SHAZAM]

Ya están listos los DVD.



-- IMÁGENES ADJUNTAS --

[promineo]

Mi regalo de reyes.