by roger (noreply@blogger.com) at 01 de September, 2010 05:00 PM
by roger (noreply@blogger.com) at 01 de September, 2010 05:00 PM
by roger (noreply@blogger.com) at 31 de August, 2010 06:20 PM
by roger (noreply@blogger.com) at 30 de August, 2010 04:21 PM
by roger (noreply@blogger.com) at 28 de August, 2010 02:46 PM
by Toni Rodriguez (noreply@blogger.com) at 08 de July, 2010 09:05 AM
Para mas información
Dingoo en WikiPedia
Si la quieres comprar ( por eBay hay de vez en cuando )
by Toni Rodriguez (noreply@blogger.com) at 07 de July, 2010 05:05 AM
Para más información
Web oficial de Game-editor
El trailer en Youtube
by Toni Rodriguez (noreply@blogger.com) at 06 de July, 2010 01:31 PM
by Toni Rodriguez (noreply@blogger.com) at 03 de July, 2010 08:44 AM
Click here to view the embedded video.
Features
Downloads
Report
After seeing the gdc10 intel talk about tasks using the vista thread pool api, I wanted to give it a try. So, the objective of this test is just try the thread pool api that vista provides. I dont try to get a massive amount of geometry on screen, just have something cpu intensive and appealing like a flock simulation algorithm.
Controls
Technology
Develop/Build/Test Machine Specs
Resources
There’s no need for setting an orthogonal view when using glDrawTexfOES for drawing text into the screen, since it seems to be ignoring any existing view or projection matrix and simply drawing into the screen buffer (and that’s probably why it is so fast!).
So no more structures like this:
gl.glMatrixMode(GL10.GL_PROJECTION);
gl.glPushMatrix();
gl.glLoadIdentity();
gl.glViewport(0, 0, canvasWidth, canvasHeight);
gl.glOrthof(-halfCanvasWidth, halfCanvasWidth, -halfCanvasHeight, halfCanvasHeight, 1.0f, 200.0f);
// draw text here
gl.glPopMatrix();It will get reduced to just…
// draw text hereInterestingly though, if you’re using fog you’ll need to turn it off or you may not see the text. So we’ll end up with this:
gl.glDisable(GL10.GL_FOG);
// draw text hereIn classic OpenGL immediate mode we use glBegin/glEnd liberally. But we can’t keep on going on like that with OpenGL ES: we are forced to convert our glBegin/glEnd calls to the glDrawArrays or glDrawElements style.
I believed that this would derive in only being able to show [boring] static geometry, but I have been messing with buffers and found out that you can for example modify the vertex buffers once they have been allocated and the data put into them. So you can not only do this:
ByteBuffer bb;
bb = ByteBuffer.allocateDirect(vertices.length * 4); // 4 bytes per value
bb.order(ByteOrder.nativeOrder());
mVerticesBuffer = bb.asFloatBuffer();
mVerticesBuffer.put(vertices);
mVerticesBuffer.position(0);but you could even do this afterwards:
for(int i = 0; i < mVerticesBuffer.limit(); i++)
{
mVerticesBuffer.put(i, (float)(Math.random() - Math.random()));
}Or in other words: buffer[index] = value is buffer.put(index, value) in buffer terms.
I haven’t tried adding more elements (the above example doesn’t add more, just replaces the current vertex values with randomized ones). The performance doesn’t seem to plummet (FPS counter shows a decent 57-60 fps) when changing all 24 vertices in my test mesh, in every frame. But I haven’t tried with larger models. And I’m not sure about the possible concurrency issues that might arise either. So it’s up to you if you want to use this — it feels a bit hackish to me :D
“Seen, gone.” is my first (serious) incursion in Android development. Yeah!
As the description says:
Take a picture, watch it morph into something different – yet related to its true origin. And before you can blink twice, it’s gone, destroyed by the very same hands that created it.
To escape from the usual demoscene non-interactive demonstrations, I decided to do something interactive but that still used a bit of processor power, so that I could see what could the platform do. I had already tried to do some audio stuff, but the results were a bit disastrous. I might come back to that field again; maybe I will be more inspired or I will know how to do things ‘the proper way’ and it will end up being a more satisfying experience.
For this, I began using Canvas and only integer math to speed things up but the results were horrible; using Canvas for this was just too much and there weren’t available cycles for anything else. It was unacceptably jerky. I even showed the app to my favourite betatester and he told me that he would uninstall the application immediately.
Since I was determined to improve things, I watched the mighty session by Chris Pruett at past year’s Google IO and understood why things weren’t quite working the way I expected them to do. After much cursing myself for not having watched the presentation before, I replaced Canvas with OpenGL ES –in which I still miss good old immediate mode, but hey… it’s way faster!– and float calculations (to my surprise, you can even afford a few float operations!), plus reorganized pretty much everything, and rewrote the rest. Core calculations could probably be optimized with native C code but I didn’t want to limit myself to non-portable code yet. Although… are there any Android devices which are not ARM based? Heh!
It’s been a very instructive experience; I’ve learnt a lot doing this –the Garbage Collector and I have become almost close friends, so to say– and obviously it will help me to create more Android applications in the future.
But in the meantime, there’s another demo waiting to be finished!
And yes, this app is what I wanted to finish a couple of days ago, just in case you missed that post.
Click here to view the embedded video.
Features
Downloads
Report
The cuda raycasting implementation is the same approach as the Stegmaier one but with some minor changes and simplifications:
The intersection code is really unoptimized. It’s just a straightforward implementation of the intersection ray-aabox function shown in “Real time collision detection” by Christer Ericson. I would suggest you to see the implementation of this function within the nvidia sdk volume render sample .
Controls
Technology
Develop/Build/Test Machine Specs
Resources

Today I decided to do something different. And I thought: Okay, I’ll try and sort out this compiling for windows issue, so that I can focus on the rest of more important things without having to worry about it any more.
And guess what…? I think I managed to do it :-)
Roughly, these are the steps I followed, just in case someone else wants to compile for windows with opengl and sdl support, using [ubuntu] linux:
#include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>WINDOWS_SDL = ./libs/sdl/windows
windows:
i586-mingw32msvc-g++ -I$(WINDOWS_SDL)/include -L$(WINDOWS_SDL) \
main.cpp $(WINDOWS_SDL)/libSDL.dll.a -o ../test.exe\
-lmingw32 -lSDLmain -lSDL -mwindows -lopengl32 -Wl,-R.(ugly hard line returns added by me so that you can see all parameters in one go).
This assumes you are invoking make from the src folder. The output will go to the parent folder. But well, the most important things that need to be highlighted are the bunch of switches you need to include in order to get the program to link:
-I$(WINDOWS_SDL)/include — this tells the compiler where to look for additional header files. This way it can find <SDL/SDL.h> and you do not need to modify the file or add #define’s when building for linux.
-L$(WINDOWS_SDL) — pretty much the same but tells the compiler to look for static libraries in the WINDOWS_SDL folder too
$(WINDOWS_SDL)/libSDL.dll.a — links the library into our binary!
-lmingw32 -lSDLmain -lSDL -mwindows -lopengl32 -Wl,-R. — these are magic – remove any of them and the linker will complain about missing symbols ;)
I still have to test this in a real windows machine; so far I have just tried with Wine. The output is a little jerky and a bit slower than the native (64 bit) counterpart, but I guess this will do much better than compiling in Virtual Box and testing with Wine :D
I’ll try to upload a test .exe when I test it on a real windows box myself, so that you can test it and see if it works in your computer (if you want, of course!). It’s ages since I compiled anything for win, and I truly wonder whether it will work with Vista/7… my last demo for Windows was done in 2005 and XP was in full glory back then :P
Click here to view the embedded video.
Features
Downloads
Report
The gpu raycasting implementation is the same approach as the Stegmaier one but with some minor changes and simplifications:
Controls
Technology
Develop/Build/Test Machine Specs
Resources
So the quest is set, the aim is clear: create something for Breakpoint 2010. There won’t be another opportunity; not at least under the Breakpoint umbrella.
The organizers have expressed publicly they don’t wish to organize yet another edition of nowadays biggest demoscene event, so it’s now or never! (At least until a new event this good takes off).
I already have had stuff of mine shown in their big screen. But that was before the true Big Screen, with capital letters. The 70 square meters one. I must release something
, I said to myself.
Of course, this means that in a way, I’m going to break my own self-imposed rule (I will release things when they are done
), but I’m working in a slightly pressurised scenario in order to finish the demo before setting off for the airport.
I have decided to keep a somewhat sporadic short demolog to keep people informed of what I’m doing, trace’s style. Hopefully it will help/force me to do things, daily, so that I don’t slack or procrastinate, and maybe you may help me too when/if I get stuck somewhere ;)
I’ll keep things short –this is probably going to be the longest post in the series– so that writing here doesn’t starve me of time to code.
This is the current status of the project:
Complimentary screenshot:

More later.
A pesar de haber impartido un par de veces una ponencia sobre la historia de los gráficos por ordenador en el cine, uno debe ser humilde y reconocer que es imposible saberlo todo sobre un tema; siempre se queda algo en el tintero, y cuando menos te lo esperas aparece uno de los blogs amigos a enseñarte algo nuevo.
En este caso, nuestro contrabandista de Moonfleet preferido nos muestra el primer corto animado de Chris Wedge. Se llama Tuber’s Two Step y es de 1985.
Para situarnos en contexto, por aquellos años Pixar se estaba formando como tal y, aunque bajo el ala de George Lucas ya habían sacado André and Wally B. (1984), aún faltaba un año para que sacaran su primer corto como empresa independiente: Luxo Jr.
Chris Wedge se empezó a dar a conocer en el mundo de los gráficos muchos años más tarde, cuando ganó el Oscar al mejor corto animado por Bunny en 1998. Este corto sí lo incluí en la historia de la animación por ordenador por sus avances en el renderizado del pelo de los animales, algo que Pixar no había conseguido ni en Toy Story ni en Bichos. Más tarde Wedge aprovecharía esta técnica en los animales que creó para su primer largo hecho con su propia compañía: Ice Age (2002).
Les dejo con el corto, que no aporta gran cosa más que su valor histórico:
Alex Roman es un artista que se ha tomado un par de años sabáticos y en este tiempo ha hecho un corto alucinante. Véanlo primero, y luego comento algunas cosas.
The Third & The Seventh from Alex Roman on Vimeo.
Hasta el minuto 6 ó 7, cuando empiezan a aparecer las esferas de agua y los pétalos al viento, estuve convencido que estaba filmado (real-life footage le llaman en english). Incluso después pensé que estos trucos estaban hechos con una excelente composición. Eso me pasa por mirar el video antes de leer sobre él (lo cual no es malo, por cierto). Fue luego que leí la entrevista que le hacen al artista en dimensión 2.5. Lo más impresionante es que ¡es todo cg! Lo ha hecho con 3D Studio Max y VRay (y otros programas para la postproducción).
Dice en la entrevista que todavía está en paro. No creo que sea por mucho tiempo, porque ya he visto este video correr por varios foros en inglés.
for(int i=0;i<NUM_DATA;++i)
{
if(data[i] <= 50)
results[i] = SMALLERTHAN_50;
else
results[i] = BIGGERTHAN_50;
}
And most of us (and myself 2 days ago) would say: "you won't get much faster than that!". Well, in fact you can. How?
result = x + (y-x) & condition
int isel( int a, int x, int y )
{
int mask = a >> 31; // arithmetic shift right, splat out the sign bit
return x + ((y - x) & mask); // mask is 0xFFFFFFFF if (a < 0) and 0x00 otherwise.
}
If a is positive, it returns x, if negative, returns y.for(int i=0;i<NUM_DATA;++i)
results[i] = isel(50 - data[i], SMALLERTHAN_50, BIGGERTHAN_50);
It works just as well... the only question is performance. What will run faster?
Elapsed time BRANCHING: 19.156000000 sec Elapsed time NOT BRANCHING: 17.566000000 sec- Using GCC with -O3:
Elapsed time BRANCHING: 2.605000000 sec Elapsed time NOT BRANCHING: 1.981000000 secThe difference is not that big without optimizations, but with them, it's clear as day: not branching gets you further. More than a 20%, in this case!!
.text:00401170 loc_401170: .text:00401170 mov eax, ecx ## eax=50 .text:00401172 sub eax, [ebx+edx*4] ## eax-=data[i] .text:00401175 shr eax, 1Fh ## eax>>=31 .text:00401178 mov [edi+edx*4], eax ## result[i] = eax .text:0040117B inc edx ## ++i .text:0040117C cmp edx, 270Fh ## if(i<NUM_DATA) .text:00401182 jle short loc_401170 ## repeat loop
j(n)le or jz instruction, but setnle. And I can't find out if this instruction does in fact flush the pipeline or not. Anyway, it still results in a faster processing when using the isel version.
.text:004010F0 loc_4010F0: .text:004010F0 xor eax, eax .text:004010F2 cmp dword ptr [ebx+edx*4], 32h .text:004010F6 setnle al .text:004010F9 mov [esi+edx*4], eax .text:004010FC inc edx .text:004010FD cmp edx, 270Fh .text:00401103 jle short loc_4010F0And, well, here's the whole testing code if anyone is curious about it:
#include <cstdlib>
#include <cstdio>
#include <ctime>
enum{ SMALLERTHAN_50, BIGGERTHAN_50};
int isel( int a, int x, int y )
{
int mask = a >> 31; // arithmetic shift right, splat out the sign bit
return x + ((y - x) & mask); // mask is 0xFFFFFFFF if (a < 0) and 0x00 otherwise.
}
int main ()
{
const int NUM_DATA = 10000;
const size_t NUM_ITERS = 200000;
clock_t startTime, endTime;
int * data = new int[NUM_DATA];
int * results = new int[NUM_DATA];
int * results2 = new int[NUM_DATA];
// Initialize test data
for(int i=0;i<NUM_DATA;++i)
data[i]= rand()%100;
startTime = clock();
// ------------------------------
// Branch test
for (int j=0;j<NUM_ITERS;++j)
for(int i=0;i<NUM_DATA;++i)
{
if(data[i] <= 50)
results[i] = SMALLERTHAN_50;
else
results[i] = BIGGERTHAN_50;
}
// ------------------------------
endTime = clock();
printf ("\tElapsed time BRANCHING: %.9f sec\n",
(float)(endTime-startTime) / CLOCKS_PER_SEC);
startTime = clock();
// ------------------------------
// Branchless test
for (int j=0;j<NUM_ITERS;++j)
for(int i=0;i<NUM_DATA;++i)
results2[i] = isel(
50 - data[i],
SMALLERTHAN_50,
BIGGERTHAN_50);
// ------------------------------
endTime = clock();
printf ("\tElapsed time NOT BRANCHING: %.9f sec\n",
(float)(endTime-startTime) / CLOCKS_PER_SEC);
// Check we didn't mess things up
for(int i=0;i<NUM_DATA;++i)
if( results[i] != results2[i])
printf ("ERROR in elem %i=%i, first value: %i, second value: %i\n",
i, data[i], results[i], results2[i]);
}
bool RetrieveProperty(object_t * object, string propName, VARIANT* pPropertyValue)
{
PropertyReader * pPropertyReader = NULL;
object->FromInterface(IID_IPropertyReader, (void**)&pPropertyReader);
if (pPropertyReader)
{
Properties * pProperties = NULL;
pPropertyReader->get_Properties(&pProperties);
if (pProperties)
{
long propCount = 0;
if (pProperties->get_Count(&propCount) == OK)
{
for (long i = 0; i < propCount; i++)
{
Property * pProperty = NULL;
pProperties->get_Item(i, &pProperty);
if (pProperty)
{
PropertyDictionary * pPropertyDictionary = NULL;
pProperty->FromInterface(IID_PropertyDictionary, (void**)&pPropertyDictionary);
if (pPropertyDictionary)
{
string bDictionaryName;
pPropertyDictionary->get_Name(&bDictionaryName);
if (!strcmp((char*)bDictionaryName.c_str(), "MY_DICTIONARY"))
{
HRESULT hr;
if ((hr = pPropertyDictionary->get_Item(PropertyName, pPropertyValue)) == OK)
return true;
}
}
}
}
}
}
}
return false;
}
Now, did anyone notice something odd? The nested ifs and loops? They make it unnecessarily hard to follow the program flow and they don't buy us anything in return!
bool RetrieveProperty(object_t * object, string propName, VARIANT* pPropertyValue)
{
PropertyReader * pPropertyReader = NULL;
object->FromInterface( IID_IPropertyReader, (void**)&pPropertyReader);
if (!pPropertyReader)
return false;
Properties * pProperties = NULL;
pPropertyReader->get_Properties(&pProperties);
if (!pProperties)
return false;
long propCount = 0;
if (pProperties->get_Count(&propCount) != OK)
return false;
for (long i = 0; i < propCount; i++)
{
Property * pProperty = NULL;
pProperties->get_Item(i, &pProperty);
if (!pProperty)
continue;
PropertyDictionary * pPropertyDictionary = NULL;
pProperty->FromInterface(IID_PropertyDictionary, (void**)&pPropertyDictionary);
if (!pPropertyDictionary)
continue;
string bDictionaryName;
pPropertyDictionary->get_Name(&bDictionaryName);
if (strcmp((char*)bDictionaryName.c_str(), "MY_DICTIONARY"))
continue;
HRESULT hr; // why do we need this, I say?
if (hr = pPropertyDictionary->get_Item(PropertyName, pPropertyValue) == OK)
return true;
}
return false;
}
Max indentation: 3 levels.
Hola planet!
Después de un periodo de vacaciones y trabajos varios he retomado el proyecto.
He terminado unas tareas que tenía pendientes referentes a la difusión del calor en 2D.
La representación del papel es un sistema masa-muelle. Este proceso irá quemando los nodos y los muelles conectados se irán contrayendo para simular las arrugas del papel.
De momento solo tengo el proceso de difusión y una deformación simple, reduciendo los muelles un epsilon. Aunque está lejos del resultado final, tiene pinta de que vamos por el buen camino
y motiva a seguir trabajando y compartiendo ideas.
También he creado una sección para ir colgando material relacionado con el proyecto.
Seguimos en contacto!

Otra de las maravillas que pude ver en el festival de animación del SIGGRAPH.
Alma from Rodrigo Blaas on Vimeo.
Éste lo vi en el festival de animación del SIGGRAPH. Es bueno que vayan apareciendo…
Gràcies, Ignasi.
Exploiting of systems is a subject of which I'd like to know more about. I think it's good to understand how avoid future hacking, but really you neither find much information on web nor books related. I've found a book which maybe could help us to improve these skills. Topics in book include:
- Program computers using C, assembly language, and shell scripts
- Corrupt system memory to run arbitrary code using buffer overflows and format strings
- Inspect processor registers and system memory with a debugger to gain a real understanding of what is happening
- Outsmart common security measures like nonexecutable stacks and intrusion detection systems
- Gain access to a remote server using port-binding or connect-back shellcode, and alter a server's logging behavior to hide your presence
- Redirect network traffic, conceal open ports, and hijack TCP connections
- Crack encrypted wireless traffic using the FMS attack, and speed up brute-force attacks using a password probability matrix
by gyakoo (noreply@blogger.com) at 20 de October, 2009 03:34 PM
I'm really thinking that C vs C++ discussion will never end. I just read a Peter Seibel post about interviews he has written in his book Coders at Work, asking to fifteen top programmers and computer scientist around the world about what are their opinions in using C++ language.by gyakoo (noreply@blogger.com) at 17 de October, 2009 06:15 PM
C++ is a horrible language. It's made more horrible by the fact that a lotJohn:
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
...
...
Well, I’m nowhere near as talented a programmer as Linus Torvalds, but I totally disagree with him. If it’s easy to generate crap in a relatively high-level and type-safe language like C++, then it must be child’s play to generate crap in C. It’s not fair to compare world-class C programmers like Torvalds and his peers to average C++ programmers. Either compare the best with the best or compare the average with the average.
...
by gyakoo (noreply@blogger.com) at 15 de October, 2009 02:53 PM

by gyakoo (noreply@blogger.com) at 15 de October, 2009 02:16 PM
Well, after some time without updating the blog I’m giving some life signals. Sorry for the lack of updates but I’ve been super busy moving to Cambridge. Yes, I moved to Cambridge to work for ArtVPS as a software developer. I’m working with real time ray tracing renderers, which is really cool. The people here are great professionals and I’m very pleased to have the opportunity to work with them. As you could imagine I have no time to do anything aside searching a flat and getting used to listen English the whole day. I left my machine in Madrid, so no tech demos in a couple of months. I have to figure out how the hell I’m going to bring all that (2 monitors, a big case, 7.1 speakers,…..) to Cambridge.
by shash (noreply@blogger.com) at 06 de October, 2009 06:27 PM
by gyakoo (noreply@blogger.com) at 01 de October, 2009 06:00 PM
by shash (noreply@blogger.com) at 23 de September, 2009 08:51 PM
by gyakoo (noreply@blogger.com) at 23 de September, 2009 04:56 AM
by gyakoo (noreply@blogger.com) at 23 de September, 2009 04:55 AM
by gyakoo (noreply@blogger.com) at 23 de September, 2009 04:55 AM
by shash (noreply@blogger.com) at 09 de August, 2009 09:45 PM
by shash (noreply@blogger.com) at 09 de August, 2009 09:45 PM
1: CMatrix4x4 CreateOrtographicProj (float left, float right,
2: float bottom, float top,
3: float Near, float zFar)
4: { 5: CMatrix4x4 result; 6:7: float tx = -(right+left)/(right-left),
8: ty = -(top+bottom)/(top-bottom), 9: tz = -(zFar+zNear)/(zFar-zNear); 10: 11: result.Set (2.f/(right-left), 0.f, 0.f, tx, 12: 0.f, 2.f/(top-bottom), 0.f, ty, 13: 0.f, 0.f, -2.f/(zFar-zNear), tz, 14: 0.f, 0.f, 0.f, 1.f); 15:16: return result;
17: }
1: CMatrix4x4 CreatePerspectiveProj (float fovy, float aspect,
2: float zNear, float zFar)
3: {4: float f = tanf (((fovy/180.f)*(float)M_PI) / 2.0f);
5: float div = (zNear-zFar);
6: 7: f = IsFloatEqual(f, 0.f) ? FLT_MAX : 1.f / f; 8: div = IsFloatEqual(div, 0.f) ? FLT_MAX : 1.f / div; 9: 10: CMatrix4x4 result; 11: 12: result.Set (f / aspect, 0.f, 0.f, 0.f, 13: 0.f, f, 0.f, 0.f, 14: 0.f, 0.f, (zFar+zNear)*div, (2.f*zFar*zNear)*div, 15: 0.f, 0.f, -1.f, 0.f); 16:17: return result;
18: }
1: CMatrix4x4 CreateLookAt (const CVector3 &eye,
2: const CVector3 ¢er,
3: const CVector3 &up)
4: { 5: CVector3 f (center-eye); 6: CVector3 upLocal(up); 7: 8: f.Normalize(); 9: upLocal.Normalize(); 10: 11: CVector3 s = f ^ upLocal; 12: CVector3 u = s ^ f; 13: 14: s.Normalize(); 15: u.Normalize(); 16: 17: CMatrix4x4 result, translate; 18: 19: result.Set ( s.x, s.y, s.z, 0.f, 20: u.x, u.y, u.z, 0.f, 21: -f.x, -f.y, -f.z, 0.f, 22: 0.f, 0.f, 0.f, 1.f); 23: 24: translate.SetTranslation (eye*-1.f); 25:26: return result*translate;
27: }Just to start a new tag “codepixel”
The whole planet here
En este proyecto hemos seguido el pipeline para la creación y animación de personajes. El objetivo era crear un modelo, con esqueleto, músculos, pelo, ropa y animación facial. Como resultado hemos creado una animación de 20 segundos.
Estoy bastante contento con el resultado. He aprendido muchas técnicas y trucos, y lo más importante, el trabajo que lleva hacer un personaje
.
Uno de los pasos más costosos fue ajustar los pesos que influyen en los vértices cuando el esqueleto se mueve. Leyendo en el foro de CG Society, los profesionales dan de 4 a 6 pasadas para obtener un buen resultado.
Agradecimientos
Caroline Larboulette and Olivier.
Algunos screenshot durante el desarrollo y producción:

En este proyecto se resuelve la ecuación de transporte convectivo con difusión en 2 dimensiones, reproduciendo una onda que se propaga a través de un dominio rectangular a la vez que se va amortiguando,haciendo uso de un malla bidimensional generada mediante diferencias finitas.
Se han parametrizado todos los valores de configuración, como la velocidad de refresco, el factor senoidal, las condiciones de contorno o la longitud del dominio, con el fin de facilitar su uso en tiempo de ejecución y que de esa manera sea más sencillo evaluar las condiciones de estabilidad (atendiendo sobre todo a los términos de Courant y D*).

Mediante este trabajo se aplican los algoritmos vistos en clase sobre deformaciones, se han aplicado entre otros volumens de revolución, twist, taper y free form deformation. Además he jugado un poquito con sistemas de partículas y naturalmente keyframes para fabricar la animación.
Influencias:Clipper de fresa (refresco riquísimo de mi tierra) Dead Note, serie anime altamente recomendable, de donde se ha extraido parte de la BSO.-> (Clipper de fresa + Dead Note) = Clipper Note
.

Este proyecto es una toma de contacto con los métodos de iluminación global, para la que se ha desarrollado un trazador de rayos muy simplificado, en lenguaje Java, partiendo de un pequeño framework con las funcionalidades básicas que no son de trazado de rayos (importación de ficheros, generación de imágens …), con el fin de centrar los esfuerzos en lo que es en si desarrollar un raytracer.
Estas son algunas de las “features” que posee nuestro trazador de rayos:
El team para este proyecto hemos sido: Pablo Quesada Barriuso, Ricardo Suárez Mesa y un servidor.
Agradecimentos a JJ: “Cuando todo falla, lo mejor es volver al origen”.

Siguiendo con la serie de trabajos realizados en el Máster de Informática Gráfica, el siguiente ejemplo consiste en resolver la ecuación de transporte convectivo con difusión en dos dimensiones. De esta manera intentaremos reproducir una onda que se propaga a través de un dominio rectangular y que a su vez se va amortiguando
En general el esquema es estable para la parte de convección cuando 0 < Courant <= 1, y para la parte de difusión cuando 0 <= D* <= 0.5. Hay que recordar que cualquier método introduce una difusión “artificial” debido al propio método, y que no tiene explicación física.
En este estudio, los valores apropiados para que el sistema sea estable han sido C = 0.50 y D* = 0.25.
- AA – Simulación Olas (rar).
Framework: Eclipse CDT & Qt Integration
Code: C++, Qt 4.4.3, LibQGLViewer 2.3.1
