# chevluh

Member

38

123 Neutral

• Rank
Member

• Interests
Art
Programming
1. ## How to offset pixel depth in the pixel shader by a constant value?

It's indeed always going to be in the positive direction. Thank you, I'm going to have a look at that!
2. ## DX11 How to offset pixel depth in the pixel shader by a constant value?

I'm trying to offset the depth value of all pixels written by a HLSL pixel shader, by a constant view-space value (it's used in fighting games like Guilty gear and Street Fighter V to simulate 2d layering effects. I wish to do something similar). The projection matrix is generated in sharpdx using a standard perspective projection matrix (PerspectiveFOVLH, which makes a matrix similar to the one described at the bottom there). My pixel shader looks like this struct PSoutput { float4 color: SV_TARGET; float depth: SV_DEPTH; }; PSoutput PShaderNormalDepth(VOutColorNormalView input) { PSoutput output; output.color = BlinnPhong(input.color, input.normal, input.viewDirection); output.depth = input.position.z; //input.position's just the standard SV_POSITION return output; } This one gives me the exact same results as before I included depth output. Given a view space offset value passed in a constant shader, how do I compute the correct offset to apply from there? EDIT: I've been stuck on this for weeks, but of course a bit after I post it I figure it out, after reading this. So, with a standard projection in clip space position.z really contains D = a * (1/z)+b where b and a are elements 33 and 43 of the projection matrix and z is view space depth. This means the view space depth can be computed with z = a/(D-b). So to add a given view space depth offset in the pixel shader, you do this: float trueZ = projectionMatrix._43 / (input.position.z - projectionMatrix._33); output.depth = projectionMatrix._43 / (trueZ + zOffset) + projectionMatrix._33;
3. ## HLSL Normal mapping, interpolation question

I'm making a simple terrain engine, and have decided to use a normal map for per-pixel lighting. The normal map's in object space, and currently at a rather coarse resolution (256[sup]2[/sup]). It's dynamically generated using the terrain's gradient, and packed into a rgb texture. The pixel shader's really simple for now, it only outputs the dot product between normal and light direction. float3 n = normalize(tex2D(NormalMapSampler, input.TexCoord).rgb * 2.0f - 1.0f); float light = dot (n, -LightDirection); float4 color = light; return color; And so I get this: To me that darker grid at texel boundaries looks a lot like the consequence of how the texture sampler's linearly interpolating the normal, but if I normalize it (as in the sample code) it does nothing (or at least nothing noticeable). Now, is there something I'm missing or are smooth normal maps like that just not meant to work up close? It's not that much of a problem because the terrain's really going to use chunked LoD so the map should never be magnified that much, but I'd like to understand if there's some error here.
4. ## [DirectX] how to enable point sampling for sprites?

D'oh! Now I feel silly for missing that. Thanks a lot for the help! EDIT: Actually, while it *is* very informative, it doesn't offer any insight on how the vertex pipeline is set up, which is the bit that actually seems to be preventing me from drawing sprites with DoNotModifyRenderState enabled. Looks like I'm not out of pixhell yet.
5. ## [DirectX] how to enable point sampling for sprites?

I'm building a small 2D application mostly using the sprite (ID3DXSprite) interface and it's working well so far. Except... I'd like to use point sampling for the textures because I need the texels to appear sharp'n'square when I zoom in. Normally I'd do that by setting the device's magfilter to TextureFilter.Point. However, When I call Sprite.End() to actually draw my sprites, the sprite sets its own various render states, including, going by the visual result, setting the magfilter back to linear. That's my problem right there. The first thing that comes to mind would be to use SpriteFlags.DoNotModifyRenderState, but in this case the sprite class won't set even the most basic settings needed to render the sprites and naturally the DirectX docs are rather evasive on what exactly needs to be done. It's in managed DirectX but the smae problem would pop up in C++ DirectX, and if someone can explain it to me in C++ I'll be able to convert it to C# easily.
6. ## Duke Nukem Forever Screenshot

Quote:Original post by AndreTheGiantI dont even really know what Diakatana is, and I dont know what it has to do with DNF. It's a game made by people who were thought to be FPS wonderboys, which they promised to be the best FPS ever, which then got through numerous delays, an engine change and several key members of the team leaving out of frustration at some point, and which when published turned out to be subpar and thus enjoyed dismal sales. People like to bring it up when talking about DNF because while DNF hasn't been published, the other bits are similar, including key members of the team leaving. All these features you list are really nice idea, is there any official source on these? While I certainly hope the 3D Realms people have created something like this, the only tangible echo we have of the gameplay is this: http://www.gamasutra.com/php-bin/news_index.php?story=8878 Which isn't exactly enthusiastic. Of course, it was an early demo, but I guess it's normal people don't find it encouraging when an early demo is all they show after all those years.
7. ## Simple collision response - collide and slide

Quote:Original post by NotAYakk So, is there any possibility that the intersection of your velocity with the plane could end up being behind the velocity, as it where? Beyond the end of the velocity? well yeah, since it occurs when the moving object's embedded in its collider, and the new distance returned by the collision function's meant to put the object right on the collider's surface. If it wasn't in the other direction it would count as a normal move and my life would be simpler. The fix still needs some tweaking because I'm pretty sure I must have introduced some fringe effects, I'll have to run through more tests before I'm certain it works.
8. ## Simple collision response - collide and slide

Dunno. that's one of the thing I lifted from Paul Nettle's code, and so far it's been working much better than tolerances. I only really want to remove that if it's actively preventing the algorithm from working correctly, and it's not. It's not not indicative of a flaw, but of a solution, and a simple, inexpensive one. The only flaw is that this solution happens to be incomplete, which is to be expected from an unfinished algorithm. Apparently he's using a variant of the same trick to solve the problem of several simultaneous colliders which I'm rather tempted to recycle too. Anyway, the point I get when colliding a surface I should be parallel to isn't as random as you seem to think: it's always somewhere along the velocity vector (simply because the collision method returns its results in terms of distance to travel, never as a new vector), and always moves the object backwards (because the object's embedded). Only the distance will be random (though it is constrained, because my colliders are convex polygons or polyhedrons, never just planes). EDIT: hahaha, actually it works now, but the fix is ridiculous: instead of trying to find how far along the normal I should go back to not intersect a collider anymore, I just use a completely arbitrary and very small value. and it works perfectly! That's kinda ridiculous but good enough for me :) [Edited by - chevluh on October 17, 2006 12:11:37 PM]
9. ## Simple collision response - collide and slide

Quote:Original post by NotAYakk The main difference here is I collided with the earliest line. Your collided with the first line you noticed checked. By moving yourself unilatrally, you could very well have teleported past another line -- not a good thing. Actually, you can't assume that, since the snippet of code I posted didn't cover how I choose my collider. And I do choose the one that minimizes movement, through a process quite similar to the one you describe. Your suggestion about adjusting the movement instead of the position is intriguing, I'll look into that. Now, as I vaguely indicated in my previous post, the "jump" comes from moving near-parallel to the colliding plane, because a collision register with a plane I'm supposed to slide on and my objects are pushed back along the direction of movement instead of being pushed back along the plane's normal, and when the direction of movement is near-parallel that means they'll be pushed back quite far. Normally this is taken care of in the collision detection method, by ignoring the last collider, since I'm supposed to be travelling parallel to it, but when bouncing back and forth between colliders it's not enough. So I added a check for dot(movement, collisionNormal) >Epsilon), which takes care of the bouncing but creates the inverse case where an object can be stuck between two others, so it'll still need some tweaking.
10. ## Simple collision response - collide and slide

Quote:Original post by Bob Janova The big jump away comes from setting the speed at the end Well, yes and no. The violent, physically correct, catapult-like effect comes from setting the speed, but only because the resulting computed movement was not the one expected. The fix you suggest only gets rid of the physical consequences ("catapulting" the object away), not the initial movement backwards. Which essentially translates into mad jittering when you push into an acute angle. I think said movement comes from sliding parallel to a plane, because of floating point errors (since in case of intersections I'm pushed away along the direction of movement, if the movement's near parallel to the surface the freeing position can be far away). Normally the collision detection routine ignores the last collided plane, because I'm obviously sliding parallel to it, but when bouncing back and forth between two objects it's not enough, so I need to work on those tolerances. [Edited by - chevluh on October 16, 2006 3:05:33 PM]
11. ## Simple collision response - collide and slide

Quote:Original post by Gagyi Shouldnt this be much easier with Verlet integration? It's quite possible, but the very title of the doc and its abstract ensured its storage in my "physics stuff, for later" folder instead of the "basic moving sphere" one :) I'll have a look at it, but I'd like to finish what I have started with the current algo, since it's doesn't seem that far from finished. The symptoms match what Oliii mentioned (incorrect behavior for angles <90 degrees, other cases are stable) and tolerences are indeed mostly missing, so I'll go in that direction for now.
12. ## Simple collision response - collide and slide

Quote:Original post by NotAYakk So, you are saying you added a check for fElapsedTime that prevents this line: m_speed=(m_position-originalPosition)/fElapsedTime; from running? precisely. And added a breakpoint to see if that check was ever true. Turns out it isn't, and my catapult seems to be unrelated. Which is kinda unsurprising, since my problem seems to be linked to specific geometric configurations rather than the flow of time. Excellent suggestion about the asserts, I'll do just that.
13. ## Simple collision response - collide and slide

The intuitive answer to that would be that if fElapsedTime is near zero the movement vector's lenth will be near zero too and the loop won't loop. Did add a check, to be sure ;) and it doesn't change anything. I think it may be a consequence to the moving object being embedded in the collider, since it's pretty much the only case where the movement would go backwards, but I don't really get why the reaction would be so violent - the sphere is suddenly moved backwards to a distance apparently greater than the intended movement, which is why it's then catapulted away as a consequence of the way I recompute speed at the end of the movement. [Edited by - chevluh on October 15, 2006 3:59:39 PM]
14. ## Simple collision response - collide and slide

I'm having some problems with my main entity movement algorithm. What tutorials and docs usually describe is collision detection, but I've found documents about how to organize your movement around its results not to be as readily available. I got Paul Nettle's docs and demo for collision detection using ellipsoids, though, and learned quite a few things from it. Anyway, the kind of response I'm aiming for is to slide against entities I collide with. The idea for the algorithm is to find the closest entity my moving object (a sphere, and all the other objects currently use bounding boxes) is going to collide with, to move the object as close to it as possible, and then to project what's remaining of my movement vector on it (the object we're collding with is only defined by its normal vector at the collision point and the distance we have to travel to hit it). This projection becomes my new movement vector, and I continue until the vector's depleted. It's simple enough in theory, but obviously I'm making some error somewhere in the implementation. It works fine as long as I'm colliding with only one entity, but as soon as I'm colliding with several objects at once the moving object may be violently pushed away from its colliders. For example in this situation the object, which should normally fall down and get stuck between the two boxes below, will be pushed upwards rather violently upon contact with both surfaces at the same time. The bounding volumes are displayed in white, by the way. Here's a look at the movement code. Defined outside of this bit are m_position and m_speed, which are attributes of the moving object, fElapsedTime, which is provided by the application, and the code uses D3DX functions for all vector math, but I think the names are explanatory enough. I'm pretty certain the problem doesn't come from the scene's collider detection method, since single-object collisions react exactly as I'd expect them to. D3DXVECTOR3 movement=m_speed*fElapsedTime; D3DXVECTOR3 originalPosition=m_position; c_MoveInfo moveInfo; bool collisionOccured=true; unsigned int collisionLoops= MAXCOLLISIONLOOPS; while (collisionLoops-- && collisionOccured && D3DXVec3LengthSq(&movement) > EPSILON) { //movement is decomposed into an unit vector for direction and a distance moveInfo.moveDistance=D3DXVec3Length(&movement); D3DXVec3Normalize(&moveInfo.moveDirection,&movement); // the dynamic collision method returns the distance to the nearest collided entity // and the normal to the collided surface if something is hit during movement. collisionOccured=m_parentScene->dynamicCollision(this,&moveInfo); if (collisionOccured){ //move entity right against the collider m_position+=moveInfo.moveDirection*moveInfo.collisionDistance; //substract the traveled bit from total intended movement movement-=moveInfo.moveDirection*moveInfo.collisionDistance; //project movement on the collided surface movement=(movement- D3DXVec3Dot(&movement, &moveInfo.collisionNormal)*moveInfo.collisionNormal); } else { //no collision, simple movement m_position+=movement; } } m_speed=(m_position-originalPosition)/fElapsedTime; If anybody's got some idea as to why it's incorrect, I'm open to suggestions. Possibly it's a rather silly error, but I've been staring at it for too long and can't seem to find it.