Jump to content
  • Advertisement

chevluh

Member
  • Content Count

    38
  • Joined

  • Last visited

Community Reputation

123 Neutral

About chevluh

  • Rank
    Member

Personal Information

  • Interests
    Art
    Programming
  1. It's indeed always going to be in the positive direction. Thank you, I'm going to have a look at that!
  2. 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. 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. 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. 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. chevluh

    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. 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. 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. 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. 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. 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. 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. 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. 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.
  15. chevluh

    Boycotting MegaTokyo Forums [rant]

    Quote:Original post by sunandshadow My principles are as follows: - Do what works. The highest priority is the success of the project, and every available (ethical) technique should be explored to see if it will help get the job done. - Do unto others as others would like done unto them, that they may in return do unto you as you wish done unto yourself. - Dogma and inflexibility hurt people (for example they are the major cause of hate crimes); always encourage everyone to look at problems from more than one perspective. Adaptability is an essential elements of civility, and civility is what keeps us all from getting abused. - Patient good humor and stalwart standing up for what's right are also essential elements of civility. Unreasonable and abusive people must be persistently resisted or else they'll walk all over everybody. - The purpose of community (such as a class involving exchange of cooperative criticism) is the mutual benefit of all members. To help others, you must flexibly look at the problem from the point of view of their goal, and try to give advice which will help with their particular project, which will also help with their growth as an artist, and which they can understand from their current level of ability because otherwise it won't be helpful at all. The point of my remaining in the rogue thread instead of starting my own thread was that I wanted to help others in that community (by teaching them about the principles of cooperative criticism as well as design principles), make friends with them, and be helped by them in return. I could go make my own thread anywhere, and did in fact make one in GameDev's art forum, but I really don't like doing art or writing alone, I'm not motivated unless it's a group project of some sort. The unique cool thing about the class that I wanted to participate in was people sharing a goal: to develop a cool character. But I watched both the people in the official class being frustrated by Merekat's continual snapping to don't do this and don't do that without ever explaining why, and the people in the rogue class including me getting twice as frustrated because they were imprisoning themselves in secondhand rules without any direct feedback from any mentor. If the rules of the class are impreding the goal of the class, it is the rules which need to change because the goal is the most important thing. But you should've started your own community thread, instead of botching another person's. If people are as frustrated with the course as you seem to think they are, they'd have followed! I mean, it's still you trying to apply your personal rules to someone else's endeavor. You seem to think the goal's more important, but that's your specific current way of thinking, and when it's a course on *process*, you can bet emphasis is gonna be put on *process*. Nobody said it was gonna be easy, or some kind of happy ride. People signed up and made the rogue thread because they were willing to try something different from what they knew, and think outside their usual box for once. And they made it because they wanted to try the process presented to them, not your way of thinking. Of course it's gonna be frustrating at some stage, learning something that challenges your previous opinions often is. But don't just go and decide others are frustrated just because you are. You see frustrated people, I see people who are gradually learning that the first design they put on paper won't necessarily be the best one, that they won't know for sure until they do try variations instead of just settling for what they instinctively think is a good design, and are put in a situation where their output is continually questioned, much like it'd be questioned by an art director in a real-life situation, and thus are pushed to outdo themselves, and do it within clear deadlines. And if you compare the results so far with the stuff some of the course people usually churn out, you'll see it's actually working. But still, the core issue is that you joined a thread dedicated to following a certain process, and decided to question the process and do your own thing instead.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!