Jump to content

  • Log In with Google      Sign In   
  • Create Account

Hodgman

Member Since 14 Feb 2007
Online Last Active Today, 02:30 AM

#5310236 Vector and matrix multiplication order in DirectX and OpenGL

Posted by on 10 September 2016 - 06:54 AM

Alright to to summarize,
 
Row major order:-
Vector is always on the left side of the multiplication with a matrix.
P = vM
Translation vector is always on the 12, 13 and 14th element.
 
Column major order:-
Vector is always on the right side of the multiplication with a matrix.
P = Mv
Translation vector is always on the 3, 7 and 11th element.

First up, I personally try to avoid using the terms row-major and column-major with matrices, because they mean different things to mathematicians and computer science people...
Maths people think that you're talking about whether you've got a matrix that's made up of basis vectors that are row-vectors / column-vectors, and comp-sci people think you're talking about the 2D->1D array indexing scheme. These are two very different things :(

Above, you're talking about the mathematical concept of "row matrices" vs "column matrices", and the comp-sci concept or array indexing is irrelevant.
 

So the only difference between HLSL and GLSL is how they layout this data in memory.
HLSL reads the matrix row by row. GLSL reads the matrix column by column.
 
So this is how HLSL layout the data in memory

0  1  2  3 
4  5  6  7 
8  9  10 11
12 13 14 15
And this is how GLSL layout the data in memory.
0 4 8  12 
1 5 9  13 
2 6 10 14 
3 7 11 15
Alright. This makes sense. Now I have to understand how I should layout the matrix in C++ and send it to HLSL and GLSL correctly.
 
Man..... Why couldn't OpenGL just read things row by row...... WHY !! :P

Not quite :D
By default, both HLSL and GLSL do actually use column-major array indexing! So if you're sending matrices from the C++ side, the individual floats should be stored in column order.
i.e. the storage order in RAM is:

0 4 8  12 
1 5 9  13 
2 6 10 14 
3 7 11 15

Despite column-major being the default element storage order, HLSL for some reason chose to make their constructors interpret the arguments in row-major storage order... I always thought this mismatch was odd, but your example shows that it makes more visual sense, as the code appears in rows on the screen after all!

In HLSL, you can explicitly choose the (comp-sci) array indexing scheme / element storage order of a matrix with:
row_major float4x4 foo;
column_major float4x4 bar;

And GLSL similarly with:
layout(row_major) mat4 foo;
layout(column_major) mat4 bar;

 

And just to reiterate: your choice of row_major or column_major array storage order has absolutely no impact on the multiplication order that you should use / no impact on whether your data is mathematically row-major or column-major (as in, whether the layout of your basis vectors is going across or down:wacko:

 

You see a lot of posts on the internet where people are doing maths one way in D3D and maths another way in GL (opposite multiplication orders), or posts where people say "D3D is row-major, GL is column-major" -- nope, old crud.

Both D3D and GL use column-major storage ordering by default (but can be overridden), and neither forces a particular mathematical convention on you (column-vectors and row-vectors are equally supported).




#5310218 Vector and matrix multiplication order in DirectX and OpenGL

Posted by on 10 September 2016 - 03:14 AM

The HLSL matrix constructor takes rows of values, but the GLSL matrix constructor takes columns of values.
So your HLSL code is putting a translation in the right column, but your GLSL code is putting a translation in the bottom row. Fun quirks...
Seeing it's rare to construct a matrix in a shader, it's very easy to overlook this differences in the two languages :|


#5310119 How to access UAVs from any shader stage

Posted by on 09 September 2016 - 08:19 AM

IIRC the only way to bind UAV's in D3D11 is to the OM stage. With this feature, I assume every shader stage gets its UAV bindings from the OM stage. If my assumption is right, you'd bind them for your VS the same way that you'd usually bind them for a PS in vanilla D3D11.

 

However, yeah as mentioned by Syntac_, if your vertex shader does not need to write to the resource, then it should use a SRV (or IA-stage vertex buffer binding if the buffer contains per-vertex or per-instance data) instead of a UAV.

 

Note that D3D's **V's are just "views" of a particular resource - they are not the resource. One resource can have several views -- such as a UAV that's used by a compute shader, and an SRV used by a vertex shader.




#5309944 Could you recommend a lightweight database?

Posted by on 08 September 2016 - 07:47 AM

Assuming that 30Hz is a normal number for either a game client or a game server to be operating at, 9000 queries per second is 300 queries per frame, which seems like a very mundane figure.

Each player probably doesn't have very much data each -- let's say 1 kilobyte for fun. That's 3000 KB or ~2.9MB. If each query needs to touch 100 bytes of that player's data, that's under 1MB/s of memory bandwidth required, and any respectable system will have well over 1GB/s of raw memory bandwidth available.

So, do you even need a database at all? Just make a dumb array in memory and keep the entire dataset loaded in RAM at all times :D




#5309877 Faster Sin and Cos

Posted by on 07 September 2016 - 03:54 PM

What about faster asin, acos, atan? :D


#5309744 Bug: Overly Sharp Highlights in PBR

Posted by on 06 September 2016 - 06:54 PM

Do you mean that they're too bright?

You need to use a HDR rendering pipeline with a good tonemapper at the end.




#5309738 How do I detect the available video memory?

Posted by on 06 September 2016 - 06:00 PM

There's no standard way to do this prior to D3D12 :(

You can use NVAPI and AGS to talk to the user's driver directly instead of using a Windows API.

e.g. NvAPI_GPU_GetMemoryInfo




#5309607 Vulkan or OpenGL ES or OpenGL

Posted by on 06 September 2016 - 12:55 AM

If you're new to GPU programming, start with D3D11 or OpenGL3 or OpenGL4.

 

If you want to demonstrate low-level GPU programming techniques, use Vulkan or D3D12.




#5309583 How Important is Concept Art?

Posted by on 05 September 2016 - 07:48 PM

Echoing the above statements about use in teams, it's also a time saving exercise. While the 3D artists are still busy finishing game A, the concept art team can begin exploring game B, and actually polish the design of every character, vehicle, important object, location, lighting mood, background scene... All before actual production on game B has actually started. This is very important for scheduling and budgeting, while still having control over what it is you're going to build.


#5309580 hierarchical task network planner using Multithreading

Posted by on 05 September 2016 - 07:41 PM

Pros:
- Planners can find the list of tasks faster using multithreading
Cons:
- When changing the world state, it needs to lock the variable so that race condition would not happen.

Modern engines don't really do threading that way any more. You wouldn't have an "AI thread" that runs concurrently with a "game thread". Instead, you have one thread per hardware core and you break up all of your code into a directed acyclic graph of dependent tasks, which are executed across all threads automatically. There's no locking, as jobs are only scheduled to execute when their dependencies have already completed... But yes, you will compute plans faster, which is the point of using every core to execute the game code :D
Once you start writing code in this 'job DAG' style, then all of your code is magically multithreaded in the same way -- the actual problem domain (AI planning, physics, graphics, game rules) doesn't matter, it's all just jobs in a job-graph.


#5309509 Hostility in the field

Posted by on 05 September 2016 - 06:31 AM

Hodgman, I find it telling that between the two possibilities of someone having a friend (after all this, calling him a mere acquaintance seems rude - God knows he could use an ally if this is the battlefield he has to fight on) willing to go to bat for him, and the same person inventing a complete being out of whole cloth, you pick the latter.
 
Frankly, I don't care what you believe.

I only brought it up as a possibility seeing as you're posting under a duplicate account, and your previous account only started a single topic here, which went exactly the same as this one... and where you described yourself in the same way that you're describing your friend now.

You've got to admit that these actions of yours give me cause to suspect that your abused friend is yourself.
 

So, technically, the field is not actively hostile - it's just so cold, so callous, so indifferent to the demoralisation (thank you, Kylotan) that it creates, that a person who has been abused his entire childhood could be forgiven if he confused such lack of compassion with hostility.
 
May God have mercy on you all.

You're talking to all of us as if we're all the people who have abused you. I'm not them. I've tried to help you, but my help is not what you need. Good luck.




#5309489 Outsourcing Team - 3D Simulation

Posted by on 05 September 2016 - 02:25 AM

Although we're Aussie based so somewhere in line with our time zone is preferable

Get in touch with the GDAA - they're the local industry representatives, who's job is to know/support everyone. I'm sure Tony would be happy to forward on details about your situation throughout the local industry for you in order to help you find someone suitable. There's quite a few small local studios that are available for work-for-hire. Disclaimer: I'm one of the small studios that's picked up work that's been shopped around this way :D

 

While working at some of the larger studios here, I've experienced them taking on mining/defense/training simulation work alongside their main games business, and at the small end of town as an independent start-up, I see the same thing!




#5309476 Multi thread rendering engine

Posted by on 05 September 2016 - 12:52 AM

There's no difference between threading graphics or any other engine system. An extremely common approach is a "job system" as described here: https://blog.molecular-matters.com/2015/08/24/job-system-2-0-lock-free-work-stealing-part-1-basics/




#5309383 Game engine advice?

Posted by on 04 September 2016 - 07:52 AM

Why not Source Engine if you like their tools? There's also any of the old Quake engines if you don't care about latest tech - even GoldSrc :)

UE4 and Unity are the most common suggestions.

You could check this out to get a more hammer-like environment in Unity: http://www.gamedev.net/topic/681626-released-realtime-csg-boolean-based-level-editor-for-unity/




#5309278 Hostility in the field

Posted by on 03 September 2016 - 01:35 AM

Hodgman: So you're saying that somewhere out there there's an office filled with companies all in the same field (theoretically) competing against each other? I can't imagine what that would be like - I assume part of the lease agreement includes no espionage or poaching; but still, the dynamics there must be unprecedented. Someone could write a thesis on the interplay there and ace it.

Read this; for the most part, game developers are not competing with each other: https://medium.com/steam-spy/your-target-audience-doesn-t-exist-999b78aa77ae#.wpqk1taap

Also, knowledge sharing within gamedev is amazingly common compared to other fields. In a previous (non-games) software job, I had a job performance indicator of whether I'd drafted one patent per month or not. It's impossible to invent one genuine breakthrough every month, so obviously this was for the purpose of hampering the competition with a large library of bullshit patents. On the other hand, every year hundreds of gamedevs appear at conferences to freely share the details of their latest work and advancements in the state of the art, patent free and usually without speaking fees... The post war idea that 'we all do better when we all do better' seems to still be alive and well rather than the post 70's alternative of 'greed is good' :D
So yeah, if people here are working on contractually super secret stuff, they'll close their (sub-)office doors, but for the most part things are pretty open, and there's a LOT of knowledge/idea/capability sharing when people mix in the common areas.
Personally, I'd find it really painful to go back to a corporate software job after working here :wink:




PARTNERS