Use D3DXVec3Project to take each point of a triangle and project it to screen space.
Take the cross product of any two screen space triangle points. This is twice the area of the triangle (in screen space).
Slightly incorrect. If you take the cross product of two points as position vectors, the magnitude of the resulting vector will be equal to the area of the triangle formed from the two points and the origin, which you don't want.
To calculate the area of the triangle formed by the points A, B and C, calculate the normal to the triangle by n = (B - A) x (C -A). The area is the length of that normal.
Pointless but interesting extra maths fact: if A, B, C are transformed by a linear transformation represented by matrix M, the area will be multiplied by the determinant of M. (Note projection matrix is NOT a linear transform ;))
So I want to display a texture across the whole screen, and it's smaller than the screen so I provide a SourceRect that's larger than the texture, scale it up to fit the screen, and provide a CommonStates::LinearWrap() as the sampler state.
However this doesn't display the texture, although I pass nullptr as the SourceRect, it displays the texture stretched across the entire screen.
What could be going wrong? It's not a feature level problem, The texture is a 256x256 (although it still fails on FEATURE_LEVEL_11_0)
EDIT: Solved, I flipped the top/bottom of the SourceRect.
From left to right: Iron Plate Armour, Steel Plate Armour, Leather Armour, as modeled by the player in the middle, and two human NPCs with default hair. I like how the Leather Armour turned out, slightly inspired by the Roman lorica segmentata with the shoulder pieces. The Steel has no texture yet, and looks like the normals need fixing as well
I'd also like to point out that the lighting and terrain are unfinished!
I admire the enthusiasm, but you'd be wise to keep in mind that sometimes less is more.
There's no quicker way to ruin a game--or, more likely, to simply send it into the abyss of non-completion--than to just throw in every idea that sounds cool. The creative act of achieving a harmoneous whole is as much about taking away as it is adding to. In fact, I'd argue that knowing what to take away (or simply not add) is the more important part.
You're right, but I'm having so much fun right now Some stuff might have to come out later, I shall give each one careful thought before I start modeling it. This sounds like really good advice for working on something really important like gameplay features, but hey, these are just items with varying stats.
Hi y'all. Hoping to set up a brainstorming session here
What, in a medieval-fantasy world a la Elder Scrolls, could armour be made from? I'm hoping to have a vast array of different armours, and perhaps the magical ones could have their own subtle abilities. All ideas welcome! Here is the most interesting subset of what I have come up with so far:
EDIT2: No longer taking armour ideas - I have 30 different materials now, but thanks to everyone who contributed! I got rid of a few, including a few of my own, and am satisfied with the final list Seeing how awesome this thread was, I might make another suggestions thread for other items (Especially weapons!) and spells
The armour categories are now divided into: Mundane, Elemental, Natural, and of course the two Divine armours accessible to demigod characters
Golden - magic properties of gold allow mage-smiths to alloy it with steel to make it stronger
Leaf - Armour made from very very tough leaves! Very lightweight.
Igneous - rocky exterior with the lava core showing through cracks
Sanguine - steel fused with blood, forged by vampire blood-alchemists
Magesteel / Necrosteel - Normal steel forged with enchantments
Skysteel - rare metal found in falling stars (meteorites)
Aphotic - this mysterious material absorbs all light...
Apocalyptic - forged in the heart of a dying star
(Apocalyptic and Halcyon armour only accessible to characters that have become demigods)
Again, all ideas welcome, and feel free to suspend disbelief/ignore the practicalities!
Solved. It was actually the DRAWING of the skybox that was causing problems. (Setting some shader constants which weren't reset for drawing meshes, making them appear black, which tricked me into thinking the textures were being lost).
- Colossal map.
- Hunger/thirst simulation
- 10-50 players per server. Incentivise sticking together in smallish groups, but not too large. Battle other groups to get their resources
- Guns and ammo are rare and valuable
- Fast zombies, slow zombies, large zombies, small zombies, zombie dogs, zombie fish...
- Motor vehicles, but also bicycles, horses, rowboats.
- Make fuel a (valuable) commodity
- Build a fortress and craft items (traps, explosives, weapons even) from stuff
- Make it winnable (maybe make one game mode winnable) Eg - "the chopper arrives in 10 days, survive until then", or "the zombies spawn at the evil pentagrams scattered about the map, visit and destroy these to win" - forces players to explore the map.
I really really don't recommend throwing everything at the card. I might point out that in any game scenario there's a limit to however many shadow maps you're going to be using in one frame anyway, because the expense of generating more than 4 shadow maps per frame, then over 4 texture comparisons when shading the scene, becomes prohibitive.
I would really create as many instance buffers as you need. Let's say you want 30 different meshes to be instance-able. (5 tree variations, 10 rock variations, 5 grass variations, 10 floor clutter variations, random props eg crates, barrels, etc etc).
Each instance requires one float3x3 for a rotation*scale, float3 for a position, float3 for a diffuse color, and 2 more arbitrary float parameters which could be used for different things, makes 16 floats which fits nicely). The total amount of data is 64 bytes per instance
You want 1000 maximum instances in the level, and you limit the number of active shadow-mappable lights to 4. This means each mesh needs 5 instance buffers. So that's
30x5x1000x64 bytes = about 9 mb of VRAM. Not a huge amount, and will be eclipsed by the shadow maps themselves. (4x1024x1024x32bpp = 16 mb)
Objects don't need to know how many cameras they are visible to. The scene can do frustum culling for all objects and lights at the same time, and write the instance buffers as necessary.
Let's take a good example from the game du jour - Slender. If you haven't played it, it's a horror game where the player walks around in first person view in a forest at night with a torch. Now obviously the torch is represented as a spot-light, which has an associated shadow map. (I think it's the only light source in the game as well as a very small amount of ambient light). Now let's say there are 100 trees in the game level. About 20 are visible to the player at any time, and 5 fall within the torch's beam. You tell me how much of a waste it is to throw everything at the card.
You could use multiple instancing buffers. One for each light for the shadow map generation, one for the scene rendering. Then you can lock them ALL, iterate through the scene and add all instances to their respective buffers as required, then unlock all and start using them to generate shadow maps and render the scene. By doing the lock/unlocking concurrently (well, interleaved), you reduce the amount of time the CPU has to wait for the buffers to be free
compare the following two strategies, given that you have 2 shadow mapped lights (makes 3 instance buffers used in total)
lock | iterate scene/copy instance data | unlock | render shadow map 1 | lock | iterate scene | unlock | render shadow map 2 | lock | iterate scene | unlock | render scene
lock x3 | iterate scene/copy instance data | unlock x3 | render shadow maps 1-n | render scene
(I assume that by the instance buffer you mean the vertex buffer that is bound to slot 1 and contains a Matrix per instance, or float3(pos)+float(uniform scale)+float(quat rotation) if you're really fancy)
Did you copy the original code from Riemer's website? That would be why it worked before, but unfortunately you've mangled it quite badly in the class-ifying process I was feeling generous this morning so I fixed it for you
Here are the changes:
- Changed the window procedure and got rid of the global "int run" variable. (In general people stay away from global variables in C++; if you want to know why, there's a discussion somewhere in the General Programming forum I think). - Only need 4 files - You didn't provide Game.h? So I basically rewrote the Game class. - Game class does not own the Direct3D interfaces - they are owned by Graphics - Initialisation of Direct3D now happens in Graphics::Graphics() rather than Game::Play() (this is probably what was causing the problem) - Got rid of the Renderer class (not needed) - Changed the PeekMessage() call, passing in NULL for the HWND parameter. This makes PeekMessage read all messages destined for the program (thread) not just the window - Renamed the OURCUSTOMVERTEX struct to Vertex and moved it out of the Graphics class - Added some stuff to Graphics class - Lots of smaller changes.