Jump to content

  • Log In with Google      Sign In   
  • Create Account


mrheisenberg

Member Since 13 Aug 2012
Offline Last Active Jan 13 2014 09:20 AM

Posts I've Made

In Topic: Is automatic state monitoring necessary in a renderer?

09 January 2014 - 06:58 PM

Do you use command lists and deferred contexts?I imagine they would complicate the sorting if you split the renderables between the different deferred contexts on different threads.Like if you have a system that automatically distributes draw calls and it messes up the draw order.

Also to add - I'm not using a second vertex buffer as an instance buffer, I'm using a buffer bound as a SRV, so I suppose my method is less efficient.The people from DICE said this technique is used in Battlefield 2, but they didn't mention anything like draw order.


In Topic: Is automatic state monitoring necessary in a renderer?

09 January 2014 - 06:27 PM

Similar to MJP and LS above, I create and array of structs that contain a 32bit sorting key, and a 32bit draw item index, then sort that array using a radix sort.
After that, I iterate through all the draw items (using the sorted indices) and ignore any redundant states (hopefully there is now a lot of redundancy thanks to the sorting pass).

Ideally, you'd structure your code so that you can disable these features (maybe a #define) so that you can validate that it's actually an optimization.

Ok just one question - why a 32bit draw item index - do you mean an integer?Why not just a direct pointer to the draw item?Isn't that the fastest possible way?

Also a question about L.Spiro's link - he talks about depth sorting, but what if I plan to instance a lot of objects?I just add their transform matrices to the instance buffer and pass instanceCount to the draw call.Does the way they are depth sorted correspond to how the GPU draws them?Or does it just draw them in random order(when instancing)?


In Topic: Using XMMatrixLookAtLH - trying to face a point, but doesn't work/crashes?

27 December 2013 - 11:11 AM

 

However, it seems me that the problem should be encountered in another way at all. But I'm not quite sure what to want to reach. If you used polar co-ordinates before, I would conclude that you actually want an oriented orbiting, because polar co-ordinates deal with a radius independent on the angle of orientation.

I'm actually using cubes so I can more easily see their rotation, for the final scene I'm trying to render a sphereflake fractal like this one:
sphereflake-2.jpg

As you can see, each sphere is rotated according to the center of its mother sphere, so the spheres never intersect/go inside eachother, however I couldn't find any guide on generating sphereflake positions online, mostly just raytracing articles.


In Topic: Using XMMatrixLookAtLH - trying to face a point, but doesn't work/crashes?

27 December 2013 - 08:59 AM



If you now want to compute a geometrical relation of those child entity to some other entity, you can do so only if all transforms involved are given w.r.t the same reference. That means to first have to ensure that the world position (and so on) of the child entity are up-to-date, what may mean to request the world position (and so on) from the parent entity and re-compute the own world position (and so on) from it, e.g. when using row vectors:

     this->transform = this->localTransform * parent->transform()

where each transform is expected to be computed as product

     matrix(size) * matrix(orientation) * matrix(position)

 

If done so, then a relation can be computed

     facing_matrix = facingFromTo(source.transform, target.transform);

where it is still to be remembered that facing_matrix is given w.r.t. the world space.

I changed the code to be like that:

 


void Entity3D::Face(const Entity3D& target)
{
XMMATRIX matrixScale = XMMatrixScalingFromVector(Scale);
XMMATRIX matrixTranslation = XMMatrixTranslationFromVector(Translation);


Transform = matrixScale * Rotation * matrixTranslation; //Creates the transform


if(HasParent())
{
Transform *= _parent->Transform; //Updates in relation to parent
}


XMVECTOR up = XMVectorSet(0.0f, 1.0f, 0.0f, 0.0f);
up = XMVector3Transform(up, Rotation);


Transform = XMMatrixLookAtLH(Transform.r[3], target.Transform.r[3], up); //Creates the final matrix}

It still doesn't work properly.Did I mess up the order?It seems right to me.Maybe there's another way to set 2 entities to face each other?I'm not entireli familiar with the math behind XMMatrixLookAtLH, so I'm not sure what's going on.

Here are 3 pictures of the:

caa32f4ae8c5ef56.png43b15a115a96585f.png
The first two happen when I call:
void Entity3D::Update()
{
XMMATRIX matrixScale = XMMatrixScalingFromVector(Scale);
XMMATRIX matrixTranslation = XMMatrixTranslationFromVector(Translation);


Transform = matrixScale * Rotation * matrixTranslation;


if(HasParent())
{
Transform *= _parent->Transform;
}
}

Right after Face(); So if might be logical to comment out Update() and only use face?So here is what happens when I only use Face():
3873363433e2c1b4.png


 
As you can see no matter at whan angle I arrange the cubes around the mother cube and the even smaller ones, when I call Face() they don't face the mother, they just clump up.What I want is for them to face it in a way that the new ones don't intersect the mother cube.This is what I want to achieve:
8226e33b7febc097.png

In Topic: Using XMMatrixLookAtLH - trying to face a point, but doesn't work/crashes?

27 December 2013 - 06:30 AM

1.) Both the looking and the looked at entities' co-ordinate frames must be given w.r.t. the same reference, or else the resulting transform will be meaningless. Although not being a proof, the branch using HasParent() let me assume that "this" and "target" probably may violate those condition.

 

The solution to this is to first compute the source and target positions in (typically) global space, and apply the "look at" onto them. If needed, transform the result back into some local space afterwards.

 

2.) It seems that you are using the local origin for both source and target position. Rotating and/or scaling (0,0,0) has no effect onto the point (if applied before any translation), hence are identity mappings. That means  that none of them need to be considered.

 

However, when computing the frame w.r.t. the world as described in 1.) then scaling and rotating is incorporated already.

Isn't Translation in global/world space?The HasParent() branch simply updates the entity's transform to be relative to the one of the parent, so if the parent moves, the entity will be moved with it.


PARTNERS