Jump to content

  • Log In with Google      Sign In   
  • Create Account


TiagoCosta

Member Since 26 Nov 2008
Online Last Active Today, 10:33 AM
-----

Posts I've Made

In Topic: Anyone guess what exactly all these mean?

26 July 2014 - 04:24 AM

To my understanding of vectors, the look at vector should be camera's position substracting the position of look at target.


That's incorrect. The look at vector should (position of look at target) - (camera's position).
 
The vector AB = B - A.
 
So:
cam.mvFacing = OgreVec3ToBourneVec3(mSceneMgr->getSceneNode("Worker00001Node")->getPosition()) - cam.mvPosition;

But it looks perhaps at the opposite direction. But I have tried to reverse the order of subtraction to no avail.

 
What exactly happens when you reverse the order of subtraction?
 
Does Ogre and Dolly use the same coordinate systems? Maybe you are mixing Left hand and Right Hand coordinates...

In Topic: Anyone guess what exactly all these mean?

21 July 2014 - 04:04 AM

Assuming that mvFacing is the look direction, then mvCross is probably the right (or left) vector because it can be calculated by calculating the cross product of mvUp and mvFacing.

 

I'm not sure about mvView. My guess about mvView is that it is the position the camera is looking at. So mvFacing = mvView - mvPosition.

 

Can you post the code where those vectors are initialized? 


In Topic: Game engine architecture

18 July 2014 - 09:09 AM

I couldn't find too much information on which ones are used in the game industry, but it would seem .fbx is a good choice?

 

Most engines use custom formats to store and load meshes at runtime. FBX is an interchange file format not optimized for runtime loading. Try to create a (binary) format specific to the needs of your engine that makes loading ultra fast, something like: <N><array of N vertices><...>, so when you load the model you can simply read the number of vertices and memcpy N*sizeof(Vertex) directly to the correct place (eg: graphics API vertex buffer).

 

My engine uses an hierarchy like this:

Actor
{
    Model
    Position
    Actor specific constants
}

Model
{
    Mesh
    vector<Subset>
}

Mesh
{
    Vertex Buffer
    Index Buffer
}

Subset
{
    Start index
    Number of indices
    Material
}

Material
{
    Textures
    Shader
    Other data
}

This way you can have multiple Actors at different positions using the same model, and multiple models using the same mesh but with different materials, etc


In Topic: [SOLVED] D3DX11CreateShaderResourceViewFromFile - deprecated.

16 May 2014 - 04:56 PM

DDS (DirectDraw Surface) is a texture format.
 
If you want to load a .jpg texture, use the WICTextureLoader (since it supports BMP, JPEG, PNG, TIFF, GIF, etc).
 
Anyway, I think that error is being caused by something else. Which Visual Studio version are you using? And did you use the appropriate project file to compile DirectXTex?

 

Did you call CoInitialize or CoInitializeEx? 

The library assumes that the client code will have already called CoInitialize or CoInitializeEx as needed by the application before calling any DirectXTex routines

 

 

EDIT:



I have tried compiling it into a library using visual studio project files from "DirectXTex\DirectXTex" and linking via "additional library paths" (or similar name) and putting a dependency of generated ".lib" in the linker. This failed to even compile with an unresolved external symbol (needles to say the linker didn't like it).

 

I'm pretty sure you have to compile it to a library in order to use it.

 

Can you write a copy of the errors here?

I've only used DIrectXTK (not DirectXTex) but I didn't have any problem linking.


In Topic: Instance data in Vertex Buffer vs CBuffer+SV_InstanceID

28 April 2014 - 04:48 AM

Did you mean TBuffer/StructuredBuffer, with CBuffer the computations will be slowers, becase when you read a value form cBuffer the hardware will omit it to all other threads into the current thread group(something that you want to avoid)?


Can you explain that a little better? Isn't the difference between cbuffers and tbuffers related to how the hardware accesses the data?

About the question, I never profiled those. But if the instance data is interlaced in between the mesh data, updating the Instanceing data will be an overkill. If you're using a seperate vertex buffer for instanced data... well I really have no idea.


Yes, I was talking about using a separate vertex buffer.

I am using the Buffer+InstanceID approch becase it is more clean, simple (and fast afc).

 
I'll do the same and if it becomes a bottleneck I'll work on a different approach.
 

Also, if you want to use per-instance data within a pixel shader, the InstanceID+buffer method probably makes far more sense than reading it from a vertex-stream in the VS, then passing it down to the VS via an interpolator.


I hadn't thought about that, since I mostly use instance data in the vertex shader, I pass instance data from the vertex to the pixel shader instead of binding a buffer to the pixel shader.

On modern hardware, there isn't really any dedicated vertex-fetch / input-assembler hardware left. Your input layout structure gets compiled into shader code (to fetch the vertex data from the vertex buffers) and this code is appended onto the front of your VS program by the driver!


Right. So the performance difference might be negligible since the generated shader code is probably similar.

PARTNERS