Hola, resulta que necesitaría las versiones hipoly (muy muy hipoly) y lowpoly (muy muy lowpoly) de un mismo modelo. Ambos deberian tener las coordenadas de textura aplicadas de forma que una misma textura sirva para ambos.

Es decir, dos versiones de un modelo al estilo Unreal Engine 3 o modelos del Doom3.

¿Alguien tiene algunos para dejarme?¿Alguien sabe de donde los puedo conseguir?

Gracias.

[la sección de descargas]

 Buenas. Acabo de subir en la sección de descargas de la página del motor una pequeña prueba de lightmaps (los de las fotos que enseñé aquella vez), pero esta vez corrriendo en tiempo real para que podais visualizarlos con más detalle. Además he implementado una pequeña consola con capacidad de registrar y ejecutar comandos.

http://sandra.sf.net


Una vez arrancada la aplicación, para mostrar la consola pulsad TAB. Una vez mostrada opdreis insertar comandos. Para obtener una lista de comandos registrados está el comando 'commands'. Existe también el comando 'quit', que provoca la salida de la aplicación.

Además, el renderer de lightmaps registra un comando especializado en lightmaps: el comando 'lmmode'. Este comando recibe una serie de parámetros que nos permitirán alterar la forma en la que se mezclan lso lightmaps con la textura base. A continuación una lista órdenes:

- lmmode onlylm. Hace que solo se renderizen los lightmaps. Es útil para observarlos con detenimiento y sacar fallos o imperfecciones.

- lmmode onlybase. Renderiza únicamente la geometría base sin aplicarle ningún tipo de lightmaps.

- lmmode all. Modo normal, textura base + lightmaps.

- lmmode scale 2. El método tradicional de mezclar la geometría abse con los lightmaps es mediante la modulación (multiplicación) de ambas texturas. El problema de esto es que al multiplicar el valor de máximo brillo (1.0) sobre la textura, queda como resultado el color de la textura base tal cual. Mediante esta orden le decimos al renderer que el resultado de esta multiplicación (lightmap*textura) la multiplique por 2. Después el resultado se "clampeará" al rango [0,1]. De esta manera conseguimos una saturación del color que sirve para dar más brillo a las superficies que realmente deben brillar.

De esta forma, una luz muy brillante podrá incluso "comerse" el color de la textura base, simulando que sobre ésta se le está aplicando una luz muy potente. Es parámetro 'scale' acepta como parámetros los valores [1,2 y 4] como factores de multiplicación. Esto es debido a que NO uso pixel shaders y las posibilidades (sin usar más de las 2 texturas obligatorias (lightmap+base)) son escasas.


- lmmode combine interp. Esta órden sirve para activar un método alternativo de combinar los lightmaps con la textura base: en vez de usar una multiplicación se usa nua interpolación de los colores. La utiildad de este método es bastante discutible y se ha implementado más que nada por experimentar. Para volver al método de "combinado" normal hay que usar la orden: "lmmode combine mod".

- lmmode interp 0.3. Este comando sirve para especificar el grado de interpolación entre las 2 texturas (lightmap y textura base) donde el valor que se le pasa (0.3 en este caso es utiilzado para calcular el color resultante utilizando una interoplación lineal:    LM*valor  +  BASETEX*(1-valor) .


Esto es todo. Perdonad de antemano por el tamaño del ZIP pero las DLLs del motor ya ocupan unos megas.
Espero vuestras opiniones.

 Seré directo: tengo que renderizar un mapa (escenario) dividido opr octrees. La geometría es estática (tengo los vértices subidos a la tarjerta en un buffer estático) mientras que los índices a renderizar son los que cambian.

¿Cual de estos 2 métodos es mas eficiente?:

1º - Crear los índices como DINAMICOS y modificar este buffer para metiendo los índices a renderizar y hacerlo de una sola pasada. (Esto es lo que hago ahora)

- Ventajas: Tengo un solo buffer de indices, que voy modificando.
- Inconveniente: Los índices se declaran como dinámicos y se tienen que modificar de la tarjeta, lo que peude ser lento.



2º- Crear los índices como ESTATICOS. En este caso cada octree tiene un buffer de indices ESTATICO que nunca se va a tocar y lo que hace es usar ese buffer para renderizar.

- Ventajas: Subo todos los index buffers a la tarjeta como EStÁTICOS, con lo que nunca se van a modificar y se guardarán en una zona de memoria donde se pintarán rápidamente.
- Inconveniente: Hya muchos más index buffers y más pequeños que con el método 1, con lo que dibujaré pocos polígonos de una sola pasada y además habrán mas cambios de index buffers y más llamadas a la GPU que en el método 1.



¿Que opinais? Tengo implementado el método 1 y quiero saber si vale la pena intentar implementar el 2. ¿Que metodos usais vosotros?

[Galeria]

 Hace poco he conseguido mejorar el proceso de generación de lightmaps para escenarios de mi motor. Antes no se empaquetaban demasiado bien los polígonos en cada lightmap y eso provocaba algunos fallos, sobretodo en los bordes de los polígonos y a baja resolución. Ahora he conseguido solucionar ese error.

Con motivo de este avance he creado una nueva sección en la página del motor para mostrar capturas de algunos escenarios con lightmaps. Estan en la sección Galeria de la página del motor:

http://sandra.sf.net

Os dejo una de las capturas, pero para no engorronar el post, podeis ver el resto de capturas en la web.



Cuando exportas un escenario desde MAX o Blender (formato *.SGEMAP), éste no contiene información sobre iluminación precalculada. Para calcular los lightmaps existe una utilidad (que también forma parte del motor) selm, que calcula la iluminación para el mapa y la incrusta dentro del fichero *.SGEMAP. De esta forma el renderer ya puede usar esa información para dibujar la escena con la iluminación precalculada.

Lo que hace básicamente la utilidad selm es leer primero los datos del escenario. Después empaqueta los triángulos dentro de los lightmaps que hagan falta. Se le puede decir que los empaquete con mayor o menor densidad (jugando con la relación espacio/calidad). La utilidad se fija en si dos triángulos forman un cuadrado o si podrían empaquetarse juntos uno al otro para mejorar el expacio y la calidad final del lightmap.

Una vez empaquetados se "renderiza" cada lightmap con un motor de raytracing/radiosidad (PiscisRT) o que haga un cálculo de iluminación básico y rápido. Se pueden establecer algunas opciones como habilitar/deshabilitar las sombras, la intensidad de las luces, la densidad de los lightmaps...

Si a alguien le interesa, sería posible usar este generador de lightmaps para precalcular la iluminación de otros escenarios que no esten en formato del Sandra Engine. Teneis el código fuente (bajo GPL) en el CVS del motor. Tan solo haría falta sustituir las funciones de lectura y escritura de datos de la aplicación. Otra opción sería añadirle la funcionalidad de leer los datos de un fichero XML y escribir el resultado en otro XML y los lightmaps como JPGs o PNGs. De esta forma podría usarse como una herramienta más estándar de generación de lightmaps. Si hay mucha gente interesada en esto, puede que me anime  ;)


Eso es todo, ved las imágenes de la galeria. Espero opiniones. Si es necesario puedo subir la aplicación para ver los lightmaps en tiempo real.

Me gustaría que me pasaseis escenarios (pueden estar hechos en MAX o Blender) para probar los lightmaps en escenarios más complejos. Por ejemplo, Haddd, ¿podeis pasarme el escenario que usasteis en el video de la cripta?

Saludos.

 He estado pensando en esto de del Sistema Operativo para juegos, que he puesto en el post de (Hacer Algo Útil) y se me ocurren ideas que podrían estar bastante bien, si se consiguiera un SO bien estratificado.

Tened en cuenta que no me refiero a crear un SO para el ordenador propiamente dicho. Sino que iria programado sobre Windows , Linux... Lo llamo SO de Juegos por la similitud que quiero darle a los SO tradicionales.

Por una parte tenemos el kernel del SO (un módulo, DLL o como querais llamarlo). Utilizando este kernel se podría construir una especie de "bash" (una shell, una especie de linea de comandos a lo linux). Como estaría construido sobre el kernel del motor podría utilizar el propio sistema de fuentes del motor para dibujar los catácteres en pantalla, o utilizar las facilidades del motor para detectar la entrada de datos de teclado o raton.

Esta shell nos permitiría poder ejecutar comandos del sistema, especialmente diseñados para ella. La shell podría tener un comando para convertir formatos de fichero. Por ejemlpo, entrarías en la shell y teclearias:

Código [Seleccionar] Expand


# convert demon.max demon.md5mesh


Despues podrías visualizar el contenido del fichero exportado con otro comando, un visualizador de mallas:

Código [Seleccionar] Expand


# viewer demon.md5mesh


Podrías crear una escena interaciva de forma sencilla:

Código [Seleccionar] Expand


# newscene "escena"
# display "escena"
# add light "escena" (0,0,0)
# add mesh demon.md5mesh
# moveto demon.md5mesh 10,0,2


Pudiendo ver la escena interactivamente mientras la vas creando y luego salvarla.
Y despues de haber construido la escena salvarla en un formato de fichero que puedas releer.

Código [Seleccionar] Expand


# savescene "escena" escena.scene


Cada comando (newscene, add, savescene, viewer, convert...) podrían ser módules separados de la shell, y esta los cargaría cuando arrancara. De esta forma añadir nuevos comandos y extender el sistema sería modulable. Perfecto para la participación de muchos programadores.

Se podrian hacer conversores, editores, etc... utilizando los propios recursos del SO de juegos, que ofrecería recursos especialmente diseñados para esto.

La idea de todo esto me atrae bastante y lo veo potente. No se si existe algo parecido en la actualidad pero yo no conozco nada.

 Hola, estoy teniendo problemillas usando la template std::set de la STLPort.

La cosa es ke kiero almacenar en un conjunto (std:set) una lista de triangulos que se van a representar. La cosa es que no quiero que se pinte 2 veces el mismo triangulo, por eso uso std::set, que se supone que es un contenedor donde todos sus elementos son únicos.

Lo stoy haciendo así:

Código [Seleccionar] Expand


class tri_indices_t
{
public:
 int a,b,c;

 tri_indices_t(void){ }
 tri_indices_t(const tri_indices_t &t){ operator=(t); }

 bool operator<(const tri_indices_t &t) const {
  return (a<t.a && b<t.b && c<t.c);
 }
 bool operator==(const tri_indices_t &t) const {
  return (a==t.a && b==t.b && c==t.c);
 }
 bool operator!=(const tri_indices_t &t) const {
  return (!operator==(t));
 }
 const tri_indices_t &  operator=(const tri_indices_t &t){
  a=t.a; b=t.b; c=t.c; return t;
 }
};


std::set<tri_indices_t> setTris;




Y para añadir cada triangulo al conjunto así:

Código [Seleccionar] Expand


for (unsigned int ifa=0; ifa<numfaces; ifa++)
{
               // añadir los 3 indices de cada cara
 unsigned int i3 = ifa*3;

 tri_indices_t auxt;
 auxt.a=pindices[i3+0];
 auxt.b=pindices[i3+1];
 auxt.c=pindices[i3+2];

 tris_added[itex].insert(auxt);

       }


El poblema es que, añadiendo 2 triangulos con vertices (0,1,2) y (0,2,3) no funciona, solo añade el primero, y no el segundo, como si el insert del set creyera que son el mismo triangulo.

¿Es un bug d set o que ocurre? PArece que si el tipo del set no es un tipo básico hace cosas raras con esto. Ya me ocurrió algo parecido con el std::map utilizando tipos no básicos como clave.

 Desde hace un buen tiempo (creo que ya puede contarse en años XD) llevo programando un motor 3d. Todo vino porque quería hacer un juego, era mi tercer año de carrera y acababa de aprender OpenGL. Cuando llevaba unos mesecitos (2 o 3) me dí cuenta de lo mal que estaba hecho mi código fuente XD (normal, era la primera vez) y empecé un proyecto que a base de esfuerzp, tiempo y e ilusión acabó en esto:

http://blastgame.sf.net
http://sandra.sf.net

Realmente el motor implementa muchas más cosas de las que puede verse en esa mísera web, pero nunca me ha dado por hacer ejemplillos de todas las features del motor y colgarlo de la web. Ahora parece que el motor no haga mucho. Graficos, audio, físicas, scripting... son cosas que tengo implementadas, aunque no de forma perfecta, pero bueno, funcionan como funcionan XD.

Desde hace unos dias he estado mirando motores para hacer un juego, y es desde entonces que me he dado cuenta de lo avanzado que está el mundo abhí fuera, y lo insulso que resulta crear un engine. Más aun cuando eres el único programador. Claro, nadie kieres unirse pq tienes un engine muy feo, y si nadie se une, una sola persona lo tiene muy difícil para hacer las cosas.

Bueno, que me distraigo, he visto como anda el mundo de los motores por ahí fuera y, creo he dejado de verle sentido a continuar con el mio. He aprendido mucho programandolo, desde que opengl me parecia un mundo esxtraño y mágico, hasta ahora, programando iluminación por píxel con fragment programs.

Ha sido un bonito camino que me ha servido además de para aprender, parqa usarlo como proyecto de fin de carrera (con matrícula de honor XD) y para estar optando a un contrato en la universidad para trabajar en gráficos. Pero llegados a este punto, ya dejo de verle sentido a continuar con ello. Por mucho tiempo ke le dedique OGRE siempre será mejor motor de render y ode mejor motor de físicas (mas que anda porke ya lo son, y tienen mas mas gente y una comunidad que les apoya).

Pensaba en dejar el motor y dedicar mis esfuerzos a algo que valga la pena. Mi motor me ha valido mucho la pena, como antes he explicado, pero creo que si continuo, ya empezará a dejar de serlo. No le veo el sentido a empezar un motor ahora (no kiero desanimaros Haddd) con todo lo que hay ahí fuera. Demasiados motores. La gente debería concentrarse en hacer uno entre todos y no decenas de motores. O tratar de hacer cosas "útiles", cosas de las que carezca el mundo de los videojuegos. Pero el qué.

Esto es lo que he estado pensando estos dias. No se que pensais vosotros. Yo estoy en una época de reflexión que no se donde llevará.

Hasta luego.

 Hola, nos proponemos desarrollar un grupo de personas un videojuego, pero tenemos dudas sobre el motor a usar. Al principio ibamos a usar el Ogre, pero al darnos cuenta de que no soporta colisiones nos fijamos en el Irrlicht, que además de colisiones soporta lightmapping y tiene utilidades para su cálculo.

El juego transcurrirá en exteriores y algunos interiores.

¿Que motor nos recomendais?

 Tengo una duda sobre como distribuir mi motor. Parece que tengo 2 opciones: una es distribuir todas las librerias estáticas y dinámicas precompiladas preparadas para ser utilizadas. Otra opción es distribuir el código fuente del motor para que el usuario lo compile y genere las bibliotecas dinámicas y estáticas. A ambos sistemas les veo sus pegas.

La pega de distribuirlo precompilado es que, como uso la STLPort para compilarlo con el Visual Studio 6, obligo al usuario a que tenga que instalarla para usar (compilar algo con) el motor.

La pega de distribuir el código fuente es que obligo al usuario a tener que compilar el motor en su máquina (necesitaría tener instalado swig), aunque el usuario podría compilarlo sin la STLPort o con ella, a su antojo.

Si usara el Visual Studio NET 2003 ¿podría prescindir de usar la STLPort? para ahorrarme estos problemas al distribuir el motor?

¿O no es un requisito demasiado alto obligar a tener la STLPort instalada? Es que me gustaría que mi motor no necesitara nada adicional para ser usado.

 Hoy me he instalado el Visual Studio .NET 2003, y para mi sorpresa, los ejemplos generados no tienen el aspecto típico de Office2003, o incluso del propio Visual Studio 2003...

¿Alguno de vosotros sabe como conseguir este aspecto?

 Hola, tenía pensado hacer unos cuantos plugins para cargar modelos y mallas en formatos externos al de mi motor. Me preguntaba si sabéis links a recursos para cargar modelos de este tipo, ya sabeis, por no reinventar la rueda. Lo ideal sería encontrar clases que cargaran internamente la información de los modelos y que se pudiera acceder facilmente a dicha info.

Estoy particularmente interesado en poder cargar modelos de Quake3 (MD3) y Doom3 (MD5).

 Hace mucho que no posteo nada sobre el motor en el que estoy trabajando. El otro dia empecé a remodelar la página, a escribir otro tutorial y a subir una nueva versión del motor.

No tengo pantallas bonitas que mostrar ni demos que corten la respiración, solo puedo mostrar mi trabajo puro y duro.

La página web del motor sigue siendo:

http://sandra.sourceforge.net

Me sería de mucha ayuda que ojearais los tutoriales y me comentarais vuestra opinion. Si alguien tiene ganas de pelea y quiere desarrollar en el motor, o para el motor no tiene más que decirlo y aportaré todas las faciliaddes y tiempo que pueda para la causa.

Si alguien tiene algún problema intentando hacer los programas de los tutoriales o lo que sea, hay unos foros abiertos en la misma página donde hacer cualquier consulta. Aunque también puedo responder por este foro.

Hasta luego.

PD: Por cierto Mars, si ves alguna falta de ortografía en la página (sobretodo acentos XD) avisame  ;)  

 Primero veamos si lo he entendido todo bien. Un singleton es una clase de la que únicamente puede instanciarse un único objeto. La forma de hacerlo sería por ejemplo, que para instanciar de una clase haya que hacerlo a través de una función tal que así:

Código [Seleccionar] Expand


MiClase Instanciamela(void){
   static MiClase *obj=NULL;
   if (!obj)
       obj=new MiClase;
   return obj;
}


Bien, yo no digo que no sea interesante que, si de una clase sólo puede haber una instancia, recurrir a este truco para asegurarse de ello. Lo que realmente no me gusta es que, el programador que use este sistema, puede estar intentando instanciar más de una vez un objeto de este tipo (mediante esta función) sin saber que está obrando mal.

Pondré un ejemplo con Direct3D: soy un progamador que no tiene mucha idea y en mi programa intento llamar 3 veces a la función Direct3DCreate9. Si uso un singletón como el anterior, podré hacerlo sin problemas, simplemente la función creará sólo la primera vez el objeto y las otras veces me devolverá nua instancia a ese primer objeto. ¡Pero el programador no sabrá que lo que está haciendo está mal! Incluso como funciona el programador puede llegar a pensar que en realidad está instanciando 3 veces el objeto, pero en realidad solo lo ha hecho una vez.

Los singletones me parecen una forma de "engañar" al programador. Asumimos que el programador es estúpido y que intentará hacer cosas que no se deben hacer. Entonces, parece que la cuestión de los singletones sea:
"Dejemos que el programador escriba un mal programa, pero que en realidad funcione"!

Yo creo que una función que instancie un objeto, debería siempre instanciar un objeto de este tipo. Sin recurrir a trikiñuelas dentro de ella. Para intentar subsanar el error del programador "cliente".
Si un objeto sólo puede instanciarse una vez deberíaestar todo bien explicado en la documentación de la clase.

Veo mucho más útil reescribir la clase anterior de esta forma:

Código [Seleccionar] Expand


MiClase Instanciamela(void){
   static MiClase *obj=NULL;
   if (obj)
       throw ErrorDeLaMuerte;
   obj=new MiClase;
   return obj;
}


De esta forma el programador sabe que ha intentado hacer algo que está mal, al menos lógicamente y lo corregirá de la forma adecuada. Si se usa un singletón de la forma anterior, el pgroamador no sabe que lo que está intentando hacer (la idea que tiene en mente) está mal planteada o tiene algún problema de comprensión con la clase en cuestión.


Bueno, eso es lo que pienso. ¿Qué opinais? Si me ilumináis, pues mejor que mejor.

[Separaria la info de posicionamiento de un objeto y la forma en que se puede representar un objeto en dos clases diferentes]

 Bueno, el otro dia me decidi a aplicar unos cambios que se me ocurrieron al motor. El motor lo empece ya hace bastante tiempo, y como es el primero que he hecho, no sabia como ahcer un motor XD. Fui aprendiendo a medida que lo iba haciendo. Esa es la razon que haya cambiado varias veces cosas del mismo `core', a medida que he ido aprendiendo. Y bueno, 2 de las mejoras que se me han ocurrido son las que voy a explicaros ahora.

MEJORA 1: SOBRE LAS PRIMITIVAS DEL MOTOR

Desde el principio de los tiempos (de mi motor) han existido unas primitivas (objetos). Por ejemplo: el objeto Mesh, el objeto Billboard, el Overlay, etcetera.
Cada uno de estos objetos contenia la informaci*n para dibujarse y posicionarse en el mundo. Es decir, la clase Mesh tiene atributos: pos, rotmatrix, size, para posicionarlo y orientarlo en el mundo; y ademas tiene las funciones de dibujo (Render()).

Con este esquema todo hya ido bien, hasta que he tenido que hacer cosas como dibujar muchas veces un mismo objeto. Me explico, imaginad que en un juego de naves hay 10 naves iguales (usan la misma malla). Hacer esto con mi motor supondria, o bien cargar 10 veces la misma malla para tener 10 objetos independientes, cada uno con su malla (la forma); o bien cargar solo una malla, pero hacer trucos como:

Código [Seleccionar] Expand


bucle(i){
   malla(i).pos=nuevapos;
   malla(i).Render();
}


Como ninguna de las 2 formas me gustaba, el Blender (y el ODE) me dieron la idea de implementarlo de una nueva manera:  Separaria la info de posicionamiento de un objeto y la forma en que se puede representar un objeto en dos clases diferentes. Asi, a grosso modo, tengo 2 clases:

La clase SpaceObject (que contiene la informacion sobre posicionamiento de un objeto) y la clase DisplayObject (que indica como se va a representar ese objeto).
La clase SpaceObject tiene una referencia a un objeto DisplayObject (a su forma).
De esta forma, se pueden crear multiples instancias de tipo SpaceObject que representan todos los objetos del mundo posicionados en su lugar, y todos estos objetos pueden apuntar al mismo objeto de tipo DisplayObject, indicandoles que todos tienen la misma forma. De esta forma se soluciona el problema anterior y se considera el DisplayObject (una malla port ejemplo) como un recurso mas (como una textura o un sonido) que se puede "mapear" sobre un SpaceObject.

Lo unico que no me acaba mucho de este sistema es que antes para crear una malla simplemente tenia que hacer esto:

Código [Seleccionar] Expand


Mesh malla("malla.3ds");
malla.pos=nuevapos;


Y ahora tendria que hacer esto:

Código [Seleccionar] Expand


SpaceObject obj;
Mesh malla("malla.3ds");
obj.displayobj=&malla;
obj.pos=nuevapos;


Pero bueno, creo que el nuevo sistema es mejor que el que tenia antes y lo hace un poco mas potente y mejor estructurado.


MEJORA 2: HIJOS EN LOS OBJETOS
Hasta ahora los objetos no podian tener hijos de por si. Ademas, para la clase World contenia una lista de objetos que hay que representar/colisionar/actualizar. Una lista plana d objetos.

Se me ocurrio que podria hacer que cada objeto pudiera tener un numero indeterminado de hijos. Y que las propiedades de los hijos tuvioeran en cuenta las del padre. Por ejemplo: el objeto brazo tiene un hijo: mano. La posicion y orientacion del hijo se interpretaria pues, como relativa a la del padre, de esta manera, al mover simplemente el objeto brazo, se desplazarian tambien sus hijos (la mano).
Otro ejemplo seria la visibilidad: tengo un objeto cuerpo, que tiene 5 hijos: cabeza y 4 extremidades. Cada uno de estos hijos podria tener mas hijos. Por defecto, al a*adir al mundo el cuerpo, cuando se intente representar el objeto cuerpo, se representaran tambien todos los hijos y los nietos del obj. Esto tb es util porque si deshabilitas el render del objeto padre (el cuerpo) no se van a pintar tampoco los hijos.
De esta manera consigo una estructura jerarquica de objetos, y posaria de tener una lista de objetos de tipo vector, a tener un arbol de objetos jerarquizado que cuelga del nodo principal del mundo.



Bueno, estas son las mejoras que estoy haciendo. A ver que os parecen. Solo es por discutir un poco el tema.

PD: Perdonad por la longitud del post! XD

PD2: Tildes deshabilitadas voluntariamente (estoy en un terminal maldito).

 Estoy teniendo un problema flipante con el tema de una función virtual. Me explico. Esta mañana he añadido a la clase Camera de mi motor una función virtual, con ánimo de que sea implementada por clases que hereden de ella. Para renderizar el mundo, le paso una referencia a esta clase a la función de render para que sepa desde donde hacer el render. El problema está en que hay algo que no funciona, y el render que muestra no tiene sentido.

Para intentar ilustrar el problema. Partimos de una versión del código fuente que va perfectamente. A partir de ese momento únicamente le añado a la clase Camera la función virtual Abracadabra (o el nombre ke sea). Y ya esta! el programa va mal!. Lógicamente nadie llama a esa función. EL propblema viene simplemente de añadir a la clase una función de este tipo:

Código [Seleccionar] Expand


virtual void alksdufgkasdhfg(void){}


Eso ya hace que le prorgama se comporte de forma extraña. ¿Que tipo de problemas puede causar esto? Nadie llama a esta función y ninguna clase hija la reimplementa.

Necesito ver la luz!.

PD: Cada dia me gusta más C++.

 Hola, stratosfericos. Estos dias he estado tirándole un poco a ODE para insertarlo mínimamente en mi engine. He de decir a su favor que la API me ha encantado (aunque sea en llano C) y que la simulación de la dinámica de cuerpos sólidos es bastante buena.
Por contra, estoy teniendo algunos problemas con las colisiones. A veces los objetos no detectan colisiones contra un trimesh, y a veces, si el objeto va muy rápido, atraviesa la malla sin detectar colisión alguna.

¿Alguno de vosotros ha hecho funcionar decentemente (de forma estable) ODE?

 Hola, vereis, tengo un pequeño problemilla intentando embeber python en C. He estado siguiendo el tutorial de edevi que escribió DeadLock. He conseguido crear una DLL en C++ que puede ser llamada como un módulo desde un programa python (o desde el propio interprete). El problema es que, parece que para que funcione, la DLL tiene que llamarse "_nombre.dll", parece que me obliga a que el fichero empieze por el carácter subrallado.

He podido solucionar esto simplemente editando el fichero *_wrap.cxx y poniendo el nombre que quiera, cambiando las lineas:

Código [Seleccionar] Expand


#define SWIG_init    init_swigtest

#define SWIG_name    "_swigtest"


por estas:

Código [Seleccionar] Expand


#define SWIG_init    initswigtest

#define SWIG_name    "swigtest"


Lo malo de esto es que me gustaría hacerlo de alguna manera automática para no tener que ir toqueteando a mano mis ficheros wrapper.  ¿Alguien puede echarme na mano?

DeadLock, yo te invoco  ;)  

 Hola, resulta que no tengo claro qué cosas puedo publicar junto con mi motor y qué cosas no. Mi motor es LGPL, y usa algunas librerías como la OpenIL, OpenAL, o la zlib. La pregunta es... ¿Puedo publicar parte de ellas junto con mi motor (binarios o cabeceras)?
La OpenIL y la OpenAL, por ejemplo, son LGPL, por lo que creo que puedo publicarlas junto con mi motor, pero siempre que incluya todo el código fuente con el paquete.. ¿es así?

 Seguramente será una chorrada, pero es que no lo entiendo: Las empresas o personas que trabajan haciendo proyectos open source de libre distribución.. ¿c de que viven?¿De donde sacan el dinero? Los creadores de Google pueden vivir de la propaganda y enlaces patrocinados (supongo), pero los creadores de programas como OpenOffice (peazo programa) o KDE o similares... ¿son todo gente que trabaja por amor al arte? ¿Son empresas serias con puestos de trabajo serios?¿De verdad se puede vivir desarrollando programas de libre distribución?

Mars... yo te invoco!

 http://www.alienware.com/press_release_pag...oarray_0512.asp

Básicamente es un sistema en el que se podrán conectar 2 tjtas gráficas a 2 puertos PCIExpress, que podrán trabajar en parelelo, para conseguir un rendimiento bestial.

Uno piensa: que mania en multiplicar la potencia gráfica cuando el verdadero cuello de botella es el bus v.v

Saludos.