Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 May 2010
Offline Last Active Jul 07 2016 05:21 AM

Posts I've Made

In Topic: Animated movies.

04 February 2016 - 11:09 AM

I think the easiest and cheapest way to get into animated movies, is to use Blender. You can create models and animations but also render them for a full movie. Actually they made a movie completely in blender with a big bunny ( don't know the name right now)


If you want to do it on your own, you have to write an engine (Rasterizer like UE4, Unity etc. or Raytracer like 3D Studio Max, Blender etc.) and store keyframes on a timeline with matrices (position, rotation, scale) for every object/objectpart in your scene. Now you can interpolate between those frames, render and store them as a video.

In Topic: This singleton keeps crashing.

24 July 2014 - 02:42 AM

This *(int*) doesnt work in my opinion, because you subtract the content of the adresses instead of subtract the addresses of the pointers. This little piece of code should just calculates the offset from the Singleton class to the covered class. So in memorylayout the ms_Singleton-member needs its 4 or 8 byte for its pointer-storage. Appended to ms_Singleton the covered-class members are aligned. So to get the right startposition when GetSingleton is used, the pointer is shifted by the calculated offset. Afaik this code was a workaround for older compilers and the newer ones automatically calculate those pointer-shiftings. I would give it a try to just cast the pointer ms_Singleton = (T*)this;

In VS2013 it should probably work, but I haven't tried it on Linux or Mac.

Btw. using int as datatype is critical, because it's size isn't constant through x86 and x64 and different OS. You should use char, short or long.

In Topic: Basic Rendering

21 January 2014 - 12:47 PM

Create the same amount of vertexbuffers, one for each object. The vertex-struct for each object can be different but you have to draw all objects with a single draw-call.


Alternative: One big vertexbuffer, copy all objects into this (one after another in memorylayout like an array). But the vertex-struct has to be the same for all objects. Advantage is, you can draw all objects with one single draw-call if you use the trianglelist-topology. If not do a drawcall for every object but with different starting indices obvioulsly.

In Topic: Octrees

21 January 2014 - 10:58 AM

Quadtrees are a 2D subdivision, octrees are 3D or "2 quadtrees on top of each other".

In quadtrees the division is only in 2 axis (x,y). So the z-position of an object doesn't matter.

In octrees the third axis is also used for subdivision, so the z-position is evaluated, if an object is in the upper or lower quadtree of an octree.

In Topic: Basic Rendering

20 January 2014 - 12:32 PM

ByteWidth is the whole size of your vertexbuffer. So you have 6 vertices defined in your OurVertices-array then you also have to allocate the vertexbuffer for same amount of space.

For explanation (simple):

Just imagine the OurVertices-array is a data-container on CPU-side. This can't directly be accessed by the GPU. To transfer the content you have to create a data-container on GPU-side and this is the vertexbuffer. The data is transfered through Map->memcpy->Unmap. Map opens a "pointer" to the allocated vertexbuffer and you can copy the data. Unmap closes the "pointer" and the gpu now knows it can access the containing data for rendering. The transfer is an expensive process and you should do it as few as possible. So for static geometry just once when creating the vertexbuffer and not on every frame. Dynamic buffers like particles should be updated when needed. You can also just update a part of the buffer. You can also delete the buffer on CPU-side, the vertexbuffer will still contain all data until it will be released.