En mi opinión deberias utilizar un vertex buffer por una malla completa o incluso varias mallas o submallas.

En cuanto lo de "orientar a objetos" totalmente el motor. Si esto implica crear clases a nivel de poligono, etc. y comenzar a utilizar polimorfismo, etc a "bajo nivel", yo lo veo un GRAN ERROR. Lo intenté en el pasado (y se puede decir que lo logré, porque funcionar, funciona, claro, ... pero como funciona es otra cosa).

En mi opinión, clases para managers, y otras cosas de "alto nivel".

Struct y PODs, para todo aquello que vaya a bajo nivel. Es mejor diseñar Orientado a Datos que Orientado a Objetos. En otras cosas porque como dice Mike Acton (Insomiac Games): "donde hay uno hay más de uno".


Se que es una opinión, y que muchos estarán en contra, pero como dice un amigo (que aparte de amigo, es un crack): "C+" mola, ... el "C++" no tanto (demasiado "+" XD).


Bueno, recuerda que es solo mi opinión.

Un salduo.

Yo he estado "desconectado" de stratos unos dias y no habia visto los links, pero hay mucho material interesante  :D gracias

Es una pena, pero la verdad es que estoy muy "pez" en esto de la GI.

A ver si saco tiempo, y me puedo poner yo también a "experiementar" con cosicas de estas.


Siento no poder echarte una mano :(

Saludos

Hola, he estado my liado con prespuestos y otras historias y no habia podido contestar desde hace dos semanas ... soy un "malqueda" :S

A la pregunta de XÑA: de momento es todo forward. Para dispositivos con fixed pipeline se utiliza solo una "configuración de renderizado", para programmable pipeline se puede utilizar single-pass o multi-pass ligthing.

La idea es que los efectos, sombras, etc. hasta ahora se ponian "a mano" en C++ en la "funcion de render", para cada proyecto en concreto. Y el sistema de "layers" te permitia seleccionar "objetos" a los que aplicar unos u otros efectos (cast/project shadows, real-time reflections, etc).

Pero visto, lo visto, esto es un peñazo insalvable, a no ser que como KneDa tengas la ventaja de tener la "funcion de render" en un lenguaje de script dinámico.


Al final estoy pasando todo a "data-drive" en ficheros de configuración LSON, con lo que para crear los RT, dibujar quads para post-screen, etc, se hace todo leyendo el archivo de configuracion.
Le voy a hacer caso a KneDa y voy a separar los pasos de los surface shaders, se renderizarán en el orden que dicte el archivo de configuración.
El deferred-shading por ejemplo, tendria que poder configurarlo desde el LSON también, así como HDR, diferentes tipos de shadows, etc.

Ya iré viendo, porque ahora hay curro, y de momento el sistema de materiales se va a quedar así, a no ser que ocurra algo de "fuerza mayor", y tenga que ponerme a "actulizarlo todo".


En cuanto a la pregunta sobre Json en c++ de KneDa: yo utilizo un "parser propio" bastante sencillito. Principalmente porque la syntaxis que utilizo para LSON no es exactamente Json. Más bien esta basado en esto: http://bitsquid.blogspot.com.es/2009/10/simplified-json-notation.html

Si que estuve buscando una vez, y encontre algo interesante: http://stackoverflow.com/questions/245973/whats-the-best-c-json-parser y un pagina con una lista de parsers, que no he podido volver a encontrar :(


Y en cuanto a lo de normalizar el atributo de la posicion del vertice lo decia porque yo marco como normalizados la normal (valga la redundancia) y los valores de color, por ejemplo, porque siempre van de 0 a 1 (o al menos deberian). En cambio la posicion del vertice puede ser cualquier numero, positivo, o negativo, y no deberia de estar normalizada. Por tanto yo en normalized para la posicvion pongo false, eso es lo que me habia extrañado.


Bueno, ya pondré como funciona esto del "data-driving pipeline" y como lo acabo de integrar con los surface shaders que tengo ahora ... cuando le pueda volver a dedicar unos dias para acabarlo.

Un saludo.

He estado leyendo otra vez tu descripción de pipeline, y me parece que lo habia interpretado mal  ^_^'

Más que las "Layers" que utilizo yo parece pipelines de renderizado tipo Horde3D, algo asi:

Código [Seleccionar] Expand

<!-- Forward Shading Pipeline -->
<Pipeline>
<CommandQueue>
<Stage id="Geometry" link="pipelines/globalSettings.material.xml">
<ClearTarget depthBuf="true" colBuf0="true" />
<DrawGeometry context="AMBIENT" class="~Translucent" />
<DoForwardLightLoop class="~Translucent" />
<DrawGeometry context="TRANSLUCENT" class="Translucent" order="BACK_TO_FRONT" />
</Stage>
<Stage id="Overlays">
<DrawOverlays context="OVERLAY" />
</Stage>
</CommandQueue>
</Pipeline>

¿Es algo parecido a esto lo que te refieres con pipeline?

Gracias por la respuesta, esta muy bien explicado todo :D

Voy con los comentarios:

Primero: me mola mucho que utilices json, ... yo tambien :D ... bueno ... más o menos ... lo mio se llama LSON pero es una "copia barata" del SJSON de BitSquid, que esta basado en json, pero con una "syntaxis" más sencilla y parecida a Lua.
De todas formas, esto lo hago en el "development content", mientras utilizo el motor para desarrollo, luego lo paso por un compiler, y genera packs binarios con tablas de offsets y compresion opcional. Pero "durante el desarrollo" mola mucho utilizar este tipo de formato :D, aunque supongo que será lo típico para webGl, pero en fin ... mola :)


3) Muy buena idea, estoy de acuerdo con lo que has dicho, deberia haberlo decidido asi desde el principio y no rallarme.
Comprobaré el formato de la geometria contra la especificacion de entrada del "surface shader" solo al aplicar el material al objeto, y hago "saltar" un tipo de warning exception o lo que sea, y reemplazo el material "que no se puede bindar" por uno generico que funcione con el formato especificado. ¿Por ejemplo, no?

Aunque hay una cosa que no entiendo de tu descripcion:

Código [Seleccionar] Expand

{ "datatype":"SHORT", "datasize":3, "offset":0, "normalized":true, "bind":"position"},
¿la posición esta normalizada?


4) Perdón por la cuarta pregunta, creo que la he "liado" un poco, a veces no me sé explicar ^^
Preguntaba por como almacenar los datos de las "propiedades" (uniforms), pero no me he dado cuenta en en js no debe haber ese problema por la naturaleza "dinamica y no tipada" del mismo lenguaje.
En cuanto a los uniforms precalculados estoy de acuerdo, yo también hago eso, por eso decia que para almacenar "propiedades" del material solo gastaba scalares y vectores, pero no matrices porque todas son para "parametros precalculados" como el worldViewProj, la inversa de la vista, etc.
Mola la semantica que le das, es parecida como dices a RenderMonkey, y, en este sentido, bastante más "flexible" que la mia, ya que no "interpreto" diferentes nombres de uniforms para los "parametros precalculados", siempre el mismo.


5) Supongo que los "pipelines" que utilizas, seran algo parecido a los "layers" que utilizo yo.
Siguiendo tu consejo deberia "colectar" los "draw calls/pasos" de cada mesh por separado, y luego ordenarlos segun la especificación plataforma (ordenar por shader, front-back, back-front, etc), para enviarlos de tirón al back-end. ¿No?
Lo cual me parece una idea "fantastica", asi que voy a probar a hacer algo asi, ya tenia algún tipo de ordenación, pero los "multi-passes" se hacian seguidos, y igual no es una buena idea.


Gracias de nuevo por las respuestas.
Un saludo

Jope con las comparaciones con floats y doubles, es bastante mas complicado de lo que parece.

Como dicen los expertos: "No importa cuan complicada creas que es la matematica de punto flotante, siempre lo será más."

En fin ... que remedio, es lo que hay ^^

Gracias por tu explicación :)

Verás, tengo algunas dudas sobre lo que has planteado, voy a explicar mi interpretación, bastante parecida a la tuya, pero posiblemente con algunas modificaciones.

En primer lugar, supongo que lo de "materiales por partes o por poligonos", te refieres a tener un mesh con varios sub-materiales (sub-meshes). Esto en mi engine es "indispensable", y asi lo tengo implementado.

En mi aproximacion un "surface shader" es lo que podriamos decir un material, y un Material Instance, una instancia de ese material.

Cada "surface shader" define los shaders que renderizan (estos shaders no están "acabados", ya que se combina su resultado para dar diferentes tipo: normal, skinned, multi-pass light, single-pass light, etc), los tipos de "uniforms" que acepta: diffuse, emissive, etc.., la "Render Layer" o "Layers" sobre la que trabaja (Default, Shadows, etc). Además para evitar la "explosion combinatoria" de los shaders, define que tipo de combinaciones de shaders puede tener.

Un material, en un principio, tiene una referencia a su "surface shader", una lista de uniforms, y estados de render (Alpha, Cull, Depth, etc). Los materiales se crean a partir de la funcion " MaterialManager::create_material( SurfaceShader::Handle shaderHandle )" con lo que se crea un "Material Instance" con los uniforms especificos del surface shader, además se copian los estados por defecto (Alpha, Cull, ...).


Y ahora mis preguntas:

1) ¿Vale la pena tener los estados de render (Alpha, Cull, etc) en cada "Material Instance" o los quito y dejo solo los de los "Surface Shader"? (De entrada pienso que me ahorraria cambios de estado al construir las "Display List" para el "render back-end")

2) La selección del tipo de shader (Skinned, Rigid, Lights , etc) me queda un poco "branchy code". ¿Alguien ha encontrado una buena solución para esto?

3) Los atributos dependen del tipo de mesh (por ejemplo pueden tener color en los vertices o no), lo que me lleva a una nueva selección del "shader program". ¿Alguna otra solución?

4) Yo guardo los "uniforms" como arrays estaticos. Divido en dos tipos de parametros en "escalares" (floats simples), y "vectoriales" (Vector4, aunque puedes coger los dos primeros floats, por ejemplo, para un vector2), ya que gasto no matrices (estos uniforms, como worldViewProj por ejemplo, los cambio desde el renderer-back-end, no desde el material), con lo que tengo que almacenar tambien las keys para obtener el parametros por nombre (U32 con el Crc32 de un string), y los indices de uniform del parametro en cuestion en el shader.
¿Alguna otra aproximacion?


5) Para utilizar varios "passes" los defines como varios materiales para el mismo modelo. Yo habia pensado en cambio de que el "surface shader" tuviera "la lista de pasos" especifica, luego hay unos "pass" especiales para acumulacion de depth, etc. que se realizan en otras "layers" del renderer.
¿Es mejor realizar los "todos los passes especificos del material del tiron", o dibujar todos los objetos por cada pass por separado como hago con los "passes especiales"?
En un principio, a mi me parece que puede depender de la arquitectura, pero no estoy seguro ¿Que pensais vosotros?


La verdad es que es un poco "trallada de olla" el sistema, pero no he encontrado demasiadas referencias, y esto me parece suficientemente flexible, aunque tengo alguna duda sobre la eficiencia de algunas cosas.


Un saludo, y gracias de nuevo

Voy a "reabrir" esto, para hacer una pregunta.

Estoy rehaciendo el sistema que tengo de materiales y surfaces shaders (que supongo que es algo parecido a lo que comentaba Gallo del GP7), y me preguntaba a que solución habias llegado tú al final, KneDa, que habias decidido, o si habias encontrado algun link más sobre el tema.

La verdad es que estoy un poco confuso también con algunas cosas, y no me gustaria tener que volver a reprogramar todo el subsistema otra vez porque algo no me" cuadre" luego, como me ha pasado ahora.

Un saludo y gracias.

Para liarte con más links, el ShadowGun que esta echo con Unity:
http://blogs.unity3d.com/wp-content/uploads/2011/09/Shadowgun_Unite2011.pdf
http://video.unity3d.com/video/3709506/unite-11-shadowgun-rendering

Video y pdf ^^

Guardan lightprobes como Spherical Harmonics, la gracia en particular es que se samplea la iluminacion de los SH por vertice, y luego se interpola y modula por pixel.

Y para resolver el "problema de los brillos" con las especulares tienen un par de trucos en personajes y escenarios, miratelo si estas interesado.

Las optimizaciones, eso si, las han echo para dispositivos moviles, depende del ordenador que cargue la app de webgl, pero creo que tendrás menos problemas, en fillrate por ejemplo.


Un saludo

Te remito al articulo que te he puesto antes, la "tecnica" original en la que esta basado tu algoritmo (el de los enteros como lo llamas) es de Dawson y el lo explica muy bien, pero repito lo dicho:

No hay una formula mágica!!!!

Si lo que necesitas es una funcion que "resuelva todo" y que encima este "optimizada" (como la optimizacion del pdf que pones) es muy dificil, por no decir imposible (ya que es lo que dicen los que saben del tema del IEEE, no yo ^^).

Lo que he puesto yo no es lo más rapido del mundo ni de lejos, ya que estas haciendo el fabs y la resta, con lo que la solucion podria parecer "redudante" con el algoritmo que tenias.

Lo que te ofrece respecto a la comparacion con un delta "float", es más precisión "relativa". Pero si quieres velocidad no es la solución, simplemente separa comparaciones cerca y lejos de cero. Con dos funciones por ejemplo.

Un saludo


EDIT: copio esto del articulo que no paro de mencionar porque me parece muy interesante y explicativo:

There is no silver bullet. You have to choose wisely.

+ If you are comparing against zero, then relative epsilons and ULPs based comparisons are usually meaningless. You'll need to use an absolute epsilon, whose value might be some small multiple of FLT_EPSILON and the inputs to your calculation. Maybe.

+ If you are comparing against a non-zero number then relative epsilons or ULPs based comparisons are probably what you want. You'll probably want some small multiple of FLT_EPSILON for your relative epsilon, or some small number of ULPs. An absolute epsilon could be used if you knew exactly what number you were comparing against.

+ If you are comparing two arbitrary numbers that could be zero or non-zero then you need the kitchen sink. Good luck and God speed.

EDIT2: Estaba repasando el algoritmo que he puesto para ver si podia elimnar el "branch code", y he encontrado que tenia una cast mal y no funcionaba con negativos ... sorry ^^. El cambio es esta linea:

Código [Seleccionar] Expand

I32 sign = (((I32)(ai ^ bi)) >> 31) - 1; // Parece que bien, pero NOOOO!!
por esta otra:

Código [Seleccionar] Expand

I32 sign = (((U32)(ai ^ bi)) >> 31) - 1; // Esta si :D

ups! ... chorrada pero importante

Hola, voy a contestar pero no me hagas mucho caso porque no piloto mucho de IEEE 754 ^^

Con lo poco que entiendo del tema, lo de restar y compara con cero: NOOOOOO! (mira "Infernal zero" y "Catastrophic cancellation" en el artículo que pongo más abajo).

Creo que el problema lo tienes en el mismo algoritmo. Con flotantes de simple precision no te deberia funcionar tampoco cerca de cero.

La razón es que es una "optimización" de la propuesta de Bruce Dawson (Valve Software) para comparar flotantes basandose en la ULP (Unit in the Last Position). Que no tendria que ver en mi opinión con epsilon, como pones de constante. (aunque realmente no se que vale esa epsilon).

El mismo Bruce Dawson expone los problemas de su tan "conocida" tecnica o aproximación: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/.
Aunque yo te recomiendo que te leas todos sus articulos sobre flotantes si estas indagando sobre ello.

Mi "corrección" con unos unittest comparandolo con el "original" esta en floats:

Código [Seleccionar] Expand


#define FLT_EPSILON_REDEF     1.192092896e-07F        /* smallest such that 1.0+FLT_EPSILON != 1.0 */

// Dawson "optimizado"
static bool is_near_equal_float(float a, float b, I32 maxDiff = 1)
{
I32 ai = *((I32*)(&a));
I32 bi = *((I32*)(&b));
I32 sign = (((I32)(ai ^ bi)) >> 31) - 1;

TY_ASSERT( (sign == 0) || (sign == 0xffffffffffffffff) );

I32 diff = (((0x80000000 - ai) & (~sign)) | (ai & sign)) - bi;
I32 v1 = maxDiff - diff;
I32 v2 = maxDiff + diff;

return (v1 | v2) >= 0;
}

// Nuevo Dawson, no tan "optimizado", pero funciona cerca de cero
static bool is_near_equal_float_new_dawson(float a, float b, I32 maxUlpsDiff = 1, float maxRelDiff = FLT_EPSILON_REDEF )
{
// Check if the numbers are really close -- needed
// when comparing numbers near zero.
float absDiff = fabs(a - b);
if (absDiff <= maxRelDiff)
return true;

I32 ai = *((I32*)(&a));
I32 bi = *((I32*)(&b));
I32 sign = (((I32)(ai ^ bi)) >> 31) - 1;

TY_ASSERT( (sign == 0) || (sign == 0xffffffffffffffff) );

I32 diff = (((0x80000000 - ai) & (~sign)) | (ai & sign)) - bi;
I32 v1 = maxUlpsDiff - diff;
I32 v2 = maxUlpsDiff + diff;

return (v1 | v2) >= 0;
}


TY_TEST( StratosFloatQuestion, GlobalTest )
{
// El mismo numero
TY_CHECK( is_near_equal_float(0.1f,0.1f) );
TY_CHECK( is_near_equal_float_new_dawson(0.1f,0.1f) );

// Lejos de cero .. no hay problema
TY_CHECK( is_near_equal_float(0.1f,0.100000000001f) );
TY_CHECK( is_near_equal_float_new_dawson(0.1f,0.100000000001f) );

// Más de lo mismo, mumeros más grandes, menos precision, ... pero sigue funcionando
TY_CHECK( is_near_equal_float(10000.1f,10000.100000001f) );
TY_CHECK( is_near_equal_float_new_dawson(10000.1f,10000.100000001f) );

// mmm ... cerca de cero ... si implementas algo de Dawson ... haz caso a Dawson
TY_CHECK( is_near_equal_float(0.000000000011f,0.00000000001f) == false );
TY_CHECK( is_near_equal_float_new_dawson(0.000000000011f,0.00000000001f) == true );

// Y con cero ya ni te cuento ^^ ... viva Dawson!!!!
TY_CHECK( is_near_equal_float(0.0f,0.00000000001f) == false );
TY_CHECK( is_near_equal_float_new_dawson(0.0f,0.00000000001f) == true );
}


Como ves he "tocado" algunas cosas para que fuera en mi framework, pero el trabajo de vuelta lo veo sencillo.
Podrias pasarlo a doubles y hacer las comparaciones haber si es el problema.

El problema aqui es el fabs y el if, si lo que quieres es eliminar branchy code no parece una buena solución, pero sabiendo que el 0x80000000  debiera ser una mascara para el signo igual se puede hacer otro tipo de "optimización".
De todas formas creo que tambien depende de si la arquitectura en la que estas trabajando tiene que realizar cambios de registros de flotantes a enteros, ... en fin que no me preguntes de como iria más rápido, tendria que probarlo en varias maquinas.


Lo que me lleva a mi pregunta: ¿para que utilizas comparaciones "optimizadas"? ¿lo necesitas en tiempo real? ¿es para preprocesar algo?

Bueno, en realidad son tres, lo siento ^^

Si es para runtime, prueba a utilizar el Dawson "original", pero ten cuidado con los numeros cerca de cero, de todas formas yo que tu me miraria el articulo. Como dice Dawson en él: "There is no silver bullet. You have to choose wisely."


Espero haberte ayudado, un saludo.


EDIT: despues del "tostón" de post he encontrado la repsuesta corta ^^:

Código [Seleccionar] Expand

// Check if the numbers are really close -- needed
// when comparing numbers near zero.
float absDiff = fabs(a - b);
if (absDiff <= maxRelDiff)
return true;


esto es lo que he cmabiado   ^_^'

Conozco el precio de esas licencias y no flipo en colores porque se lo caro que es el desarrollo en una consola "grande".  A mi me toca las bolas mucho el hecho de tener que pagar por la base para optar a la licencia ios. ¿Entonces que clase de licencias separadas tienen si al final tienes que pasar por caja por algo que igual ni usas?, para eso no marees la perdiz y vendelo todo junto y dejate de pamplinas

Siento, "ocupar" el hilo, y no "hablar directamente de cosas para el Wave", pero tengo mi opinión sobre lo que dice Eskema.

Creo que lo importante del precio no es lo "caro del desarrollo", sino el "provecho" que se le puede sacar. En un principio no deberia importar si haces un juego de PC con la "Pro" o uno de iOS con la "indie", pero en la realidad, creo que se le puede sacar más provecho a iOS, por una menor "implantación" de la pirateria (por ejemplo).

Se que puedes estar en desacuerdo conmigo, y puedes tener razon, pero también entiendo que 2300€ por este tipo de tecnologia, está bastante bien (aunque yo desarrolle la mia propia ahora, con anterioridad lo he gastado en diferentes proyectos, en diferentes plataformas, con gastos muy superiores).

Que no aprovechas la version "Pro" de PC, que podias tener una versión "más barata" solo con una "Indie" de iOS, cierto también, pero has de reconocer que les ha salido una "buena estrategia comercial de enganche", y están "copando" el mercado Indie.


En fin no quisiera que pensanses que creo que no tienes razón, que la tienes, solo intento dar otro punto de vista ^^
Un saludo

Por ejemplo los joputas de unity (lo siento no tengo otra palabra para ello), venden su licencia pro, dado que yo le doy caña a IOS, la licencia de pc me la trae al pairo en este momento, pero si quiero IOS pro tengo que pagar pc pro tambien y me soplan 1200€ por algo que tal vez ni llegue a usar en la vida, con lo cual la broma añadiendo el iva (otra cabronada) se me sube a 2300€ para poder tener ios pro y pc pro, cuando con la mitad iria sobrado por mi situacion actual.

La palabra me parece un "poco fuerte", pero puedo entender tu frustración.
Por suerte, seguramente, no hayas visto el precio de las "licencias de Unity3D para consolas" ... o estarias flipando en colores XD

Creo que el camino entonces es C++ conseguir un buen nivel, hacer proyectos interesantes conseguir mucha experiencia con bibliotecas estándares como la STL o Boost. Hacerte un buen portafolio y poco a poco ir dándote a conocer, el problema que le veo es que los estudios españoles que son la opción mas clara para entrar en el mundo profesional no suelen pedir esto sino alguien que sepa o Unity, o CoronaSDK o UDK y demás tecnologias especializadas.

Llego un poco tarde, pero ojeando he visto lo de STL o Boost ... y no he puedo evitarlo, lo siento  ^^
Muchos te dirán que están suficientemente maduras y que son la bomba (hablo de gente "pro" con títulos en el mercado, no de cualquiera), y otros se horrorizarán hablando de fragmentacion de memoria, los malos que son los try/catch de los allocadores, la "complejidad" innecesaria en algunos casos de los iteradores, los fallos que siguen habiendo en muchas plataformas (hay gente que se ha tenido que reprogramar la STL entera para que los luchadores no salieran "en pelotas"), y que vivan los arrays de toda la vida (tambien te hablo de "pros").

Yo estaré más o menos al medio de ambas opiniones ... o quizás no ... en runtime NUNCA utilizo STL ni Boost, ni megaultratemplates que tardan "eones" en compilar, y algunos gcc directamente te lo escupen a la cara.
En cambio cuando hago herramientas en C++, basicamente programas de linea de comandos para compilar assets, etc. me "harto" de usar STL list, vectors, string, etc. Es muchismo más comodo.


En cuanto a lo que te pueden pedir, si es un estudio "más pequeño" que es lo más habitual aqui, buscarán una licencia "asequible" de una tecnologia, aunque esta esté cerrada, y buscaran a gente que controle de esa "tecnologia" (como es lógico).

Aprender estas "tecnologias especificas" como las llamas te pueden valer para "tomar contacto" con las "soluciones" a los problemas de desarrollo que ofrecen las mismas.
Ya que si quieres desarrollar tu propia version de alguna tecnologia (IA, fisicas, graficos, ...) lo primero es que pruebes lo que hay, como funciona y que se puede mejorar (según Picasso: "los grandes artistas copian, los genios roban").


Y como dices para avanzar en tecnologia hay que pegarle al C++, pero hay que pegarle mucho, muchisimo.
También hay empresas en España que demandan a gente "especializada", no nos engañemos.
Pero normalmente se busca a alguien con un "curriculum" si piensas en asignarle un subsistema del engine entero para él solito.


A mi no me parece tan mala idea que comiences a darle caña a Unity, UDK, etc., si llegas controlar algo, es un buen punto de comienzo para poder "entrar en la industria", una vez dentro todo cambia, comenzando por la percepción que puedas tener de la misma.

Una vez dentro si te ves con "coraje" para seguir (muchos colegas han sido "inteligentes", han desertado de los "jueguecitos", y han vuelto a trabajos más "tranquilos y bien pagados"), y estás dispuesto a seguir perdiendo horas por la noche en casa, y levantarte a las 7 y media al dia siguiente para ir al estudio, ... ¡Enhorabuena!, de repente un dia de das cuenta de que NO SABES NADA.
Pero al menos, te pagan al final de mes.

En fin espero no ser demasiado deprimente.
Un saludo y ánimo :)

Respecto a lo que comentabas de como aparentar ese profesionalismo, supongo que como dices no os queda otra que enseñar muchos tutoriales currados al estilo del bootcamp de unity para que la gente vea lo que se puede hacer con el motor, no me vale que me digas mira el bye bye brian, quiero ver el proyecto, quiero ver el codigo y quiero ver como de facil es manejarlo todo.

Se me olvidaba, tutoriales!
Estoy de acuerdo con Eskema,yo comencé a gastar Unity3D por el tuto del "3D Plataform", que te enseñaba a "acabar" un proyecto medianamente hecho, y demostraba la facilidad de desarrollo, y el mínimo tiempo necesario para iterar.
Esta muy bien, de echo creo que es de los mejores tutos (en cuanto a "utilidad real") que he visto. Yo le echaria un vistazo, aunque solo sea por pillar ideas de como está enfocado.
De echo, igual tener una "version demo" del engine, y un tutorial de ese rollo, free en la web, o lo enviais personalmente, al estudio que lo solicite por mail aportando sus datos (como hacen muchas compañias), puede dar a conocer las ventajas de desarrollo que ofrezcais.


Y volviendo a lo que dices de los precios, yo menos de 200$, como he leido por ahi, NO le pondria (aunque es mi opinión).

Otra cosa, que podeis hacer, es preparar una especie de "version beta", buscar un par de "estudios" o "colegas" que conozcais  y que sepais que van a sacar un buen producto, y llegar a un acuerdo con ellos.
Mejor precio/financiación y "soporte personal" (creo que este caso seria importante "personarse" para ayudar y arreglar cosas), a cambio de sacar más "buenos productos" todavia, para cuando lanzeis el engine, y de que os ayuden a mejorar el mismo, no directamente programando, sino más bien indirectamente, ya que esa "experiencia" es la que os ayudará a "pulir" el sistema y ver las "necesidades" de otros estudios (en mi opinión).

Yo, de echo, si alguna vez licencio mi motor a "alguien de fuera", será de esta manera: no saco mucho, pero puedo estar más tranquilo si es de "confianza" al mover el código fuente, etc.

Adew!