vajuras

Members
  • Content count

    266
  • Joined

  • Last visited

Community Reputation

139 Neutral

About vajuras

  • Rank
    Member
  1. many shadow maps

    Quote:Original post by grzegorc hey, very thanks for the answers! now I need to ... understand them.. (sorry but I am a beginner :( ) yeah, I heard something about 'deferred rendering' but I thought I can skip this topic as it seems complicated and I don't have much time with my work. But it seems that I will need to learn something about it. I have found this tutorial: http://www.catalinzima.com/tutorials/deferred-rendering-in-xna/ seem to be ok, but if know anything else what is also good be let me know. Yeah Catalina wrote a great tutorial. I took a look at that one. It has all the steps. I can't recall if it has a shadow mapping step though. Riemer's also has a deferred rendering tut as well however, like Catalina, I believe it also lacks the shadowmapping step (whereas the point/spotlight can cast shadows). But it does demonstrate how all the lights in the scene all contribute to the light accumulation buffer Quote: accumulation buffer nice thing! "The accumulation buffer is simply an extra image buffer that is used to accumulate composite images." right? ok, lets assume that I know what accumulation buffer is. The question is what should I accumulate? Lighting information (light factors for each light)? Or should I accumulate all shadow maps into one shadow map? Yes, the first part is correct. you are collecting all the contribution from your light sources. Light Diffuse + specular. Quote: Something like this comes to my mind: for each light 1. render shadow map for light to texture 2. render scene with this one light + with shadow from above shadow map 3. add scene from point 2 to accumulation buffer end for render accumulation buffer as final result is this ok? Yes that sounds correct. The light accumulation buffer is composited into the final image along with Materials, etc. And to be clear, the reason why a lot of people do thing this way is so that they only need 1 shadowmap in video memory. This is how I do things (but dont want to bog you down with detail): 1. Break up view frustum into 4 sections. Render all 4 sections to 1 shadow map 2. Run the GBuffer step 3. Render to full screen quad (direction light shader goes here). 4. Next run though point/spotlights 5. for every light, reuse that same shadowmap. Render to it 6. Switch to Deferred shader for the light. Project the shadow into light accumulation render target 7. After all lights have been renderered, composite this buffer into the final image
  2. many shadow maps

    What I do is use a light accumulation buffer (see deferred rendering). During the lighting phase I do this: 1. For every light in the scene, render from its perspective into a shadowmap 2. Now switch to the deferred point/spotlight shader. While rendering the light (using alpha blending), sample the shadowmap and project the shadows into the light accumulation buffer From what I gather, most techniques seem to involve having all of the lights contribute to a light accumulation buffer and then later, this render target is composited into the final scene
  3. Nice, I figured it was the frustum corners that got you. Yeah I was worried I would get the order wrong as well. Good job!
  4. You should checkout PSSM (OpenGL implementation): http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/ I personally did the DirectX implementation (I am not terribly familiar with Open GL). I'm aware that you are only interested in 1 shadow map however, I believe you will still need to do the same core work such as build a tight fitting bounding box to contain the scene. 1. As you pointed out, your matrix is ortho, so only the direction should play a factor. The position of the sunlight (eye) is basially zero. Your target can basically be the forward vector of your sunlight matrix. 2. Basically you would need to build an AABB that contains everything *both* camera & light both see since the sunlight sees elements the camera cannot see however they cast shadow into your scene. This is the only part where you compute an actual sun world position only to build a frustum for it. You can use both frustums (light + camera) to figure out all the elements they touch. It may suffice to simply back the sunlight behind the camera a few units to grab all the elements that can possibly cast shadow into the viewable area. There is probably some really intelligent algorithm out there. I personally just picked a nice dist for my sun since my scene is fairly simple atm. Code: For building the ortho matrix for my Sun, I used the DirectX function D3DXMatrixOrthoOffCenterLH which takes the projection matrix and dimensions of my viewbox as arguments
  5. Well a LOT can go wrong when you reconstruct a world position from the depth buffer. In my experience, 2 things can go wrong once you get to your point: 1) Frustum corners are not correct. This can occur if you mistakenly declare the Vertex declaration of the QuadVertex struct incorrectly. For instance, I once got the stride wrong. So I always sent the same frustum corner over & over 2) You might need to do part #2 of his tutorial and compute 'world position' rather than in view space. What you can try doing is move on to point lights. they are simplier to do using his method because they do not require the frustum corners. Once you get a basic point/spot light working, then you have the issue narrowed down to the 4 frustum corners. Another option would be to search this forum for wolf's post that I believed was titled 'reconstructing world position from depth'. In that post, they discuss another approach to compute a viewspaceray using TanHalfFOV & ViewAspect (technique from Shader 5 book I think he said). that approach doesn't require the frustum corners so it can be simplier to get working. It also results in linear depth. I got both techniques working over the weekend. Oh btw, worse come to worse, you can always just store XYZ directly into a 128 bit texture if your card supports it (its a big performance hit though but its just decent to start off with). You can also just pack the XYZ directly into a 64bit floating point texture directly
  6. Customization vs Precreated Spells

    didnt HERO system (superhero pen and paper) already develop a way to create powers?
  7. Quote:Original post by Iron Chef Carnage I was thinking about this in terms of EvE. Wars tend to suck because when a Russian corporation goes to war with an American one, their fleets seldom meet, due to timezone disparities. When you can get 50 guys in ships, the other team has about ten members on, and they know better than to start anything. My idea works well in terms of EvE fiction, thanks to synaptic interfaces and hyperlight communication and travel, so I'll discuss the idea in those terms. So how about letting players set their character to do something while offline? Let them inhabit a ship remotely. You buy the ship, you fit it, you put it in your hangar, and then when you log off you set that ship to be your active vessel, and your character goes into hibernation with his diminished brain function being dedicated to operating that vessel. Set up a task or a patrol route or whatever. Basically, there are NPC spawns that are actually player characters, behaving in some defined way. They're dumb, but they can do basic things like hauling assets, camping a gate or maybe even mining. This was an excellent idea BTW in Starport your character is always persistant. So, if you logout on a planet your ship is still online. I think it works because you can takeover planets and setup NPC turrets. The server 'rebangs' though at some point after a few weeks or months. So that might cleanup absent subscribers there I also liked the ideas about NPC merchants taken your place. The idea about AFK players doing mining and other simple tasks I thought was plausible too. I am only thinking from a pure design perspective. I never really take other stuff into consideration like 'mass' appeal. The benefit though if a consumer is paying for a persistant character anyway well it makes sense too me to reward them at all times. just one angle to look at this
  8. Thanks I'll check it out
  9. I read the FAQ which helps out a lot maybe it anwsers all my questions. I suppose I go UDP it sounds like server side I'll run a listener in its own thread. I think its all covered in the FAQ
  10. I guess this question gets asked a lot. I'm getting ready to start coding network support for a game. Hoping to aim for 5,000 players. Was hoping perhaps someone knows of a paper or book I should order? I was thinking to use TCP/IP What part of a multiplayer server is multithreaded btw? Do I just code a single listener and then pass on events to another thread? you know like receive event -> store to queue -> another thread will grab events in the queue at their leasure So I'm just looking at two threads? one for listener then another thread I suppose for my game code? Just need some basic tips to get me pointed in right direction by the way my client is already multi-core and pretty well fleshed out its the server that scares me
  11. the key to eliminating 'grind' - well I am not so sure but if the game is a true sandbox you should be able to progress doing what ya find fun. In EVE, I enjoy combat and manufacture so im pursuing those goals. But I enjoy learning new game mechanics. I've only mined like twice total over many, many hours now. the key I think is just give players a lot of options if possible. mini-games, contest, player run events, missions, etc They can still grow tired of fighting even a common enemy I'd like to see more focus on non-combat (and of course attention to combat)! Also ways to get newbies into PVP and contribute meaningfully!
  12. sry just got done playing blue dragon demo. it does something weird. random encounters are gone true- but the map still transitions to a battle screen. its 3rd person view at all times though.
  13. btw if resources is an issue you might want to checkout MArvel Ultimate Alliance. They stuck to overhead view and did a wonderful job. not sure about the PC version but I know the xbox 360 version rocked! sometimes it would transistion into a 3rd person behind character view seamlessly for the boss fights. was fun, fun game!
  14. What I'm envisioning for this is overhead 3rd person view (diablo, titan quest) then switch to a normal behind view for action sequences for your idea if this is what you want to pursue. yeah that is 'classic RPG' style though that is the only issue. Single player RPGs like Blue Dragon & latest squaresoft titles have abandoned the Random encounter approach. but it has worked fine for years so maybe it can work for you you can give gamer the option to transistion from behind the view --> first person during the encounter. some like first person view in RPG while others love to see their avatar at all times. I like to zoom my cams way out when given the choice so I can see all the obstacles
  15. SKILL VS LEVELING IN MMOs

    Quote:Original post by Sandman Quote:Original post by Sirisian For a person stuck with a class they are forced to do the best with what they have. Sounds like bad game design to me personally, but some people like that. I strongly disagree with that. Doing the best with what you have is a fundamental part of what makes games fun, in my opinion. It forces you to develop creative and interesting strategies to cope with problems you aren't optimized to deal with. You can't play chess with fifteen queens. You have to make do with the pieces you have. Even more so as you lose pieces throughout the game. That's an important part of what makes chess interesting. Quote:[i]Original post by Nathan Baum I don't think so, for three reasons: 1. If you begin to specialize in a particular field but later decide you don't like that field, it's not too late to specialize in a different field instead. In a class-based game, if you can't switch classes then you have to redo your character if you want to change roles. If you can switch classes this reason might not apply, depending upon how class switching works. Strictly speaking, this is potentially just as big a problem for skill based systems as for class systems. It all depends on how they are implemented. For that reason, I don't this point really counts. Quote: 2. Depending upon how fine-grained skills are, you can specialize in whatever fields you like. Most games won't have a specific class for fighters with powerful fire magic and pick-pocketing, but a purely skill-based system would allow a character to set himself up that way. Again, much depends on how classes are implemented, but I suppose this is a somewhat reasonable point. However, bear in mind that a properly designed class will always be useful, having a set of abilities that are synergistic. Throwing fireballs is not terribly synergistic with melee combat, unless you're OK with being stabbed in the face whilst casting, and then incinerating yourself when your spell finally goes off. It doesn't even work that well with ranged combat, since you can't shoot a bow and launch a fireball at the same time. Those two skill sets are exclusive rather than synergistic, which makes them a sucky combination. A class system can cut out all the silly combinations that don't work well together, reducing the player's chances of inadvertently gimping himself to the point of uselessness, and reducing the likelihood of the player saying "oops my character sucks, time to rebuild". What is useless to a Game Developer can be insanely fun to the player. In skill based games you'll see all kinds of crazy creativity. Right now in EVE I'm a combination of manufacter and fighter pilot. Sure, I might get my rear end handed to me in a fight but I'm happy because I invested time into what I really want to be When players are forced along a treadmill you might end up with a character you don't really like. In City of Heroes, players all the time try to build their healer/tank/warrior how they want but they are still powers people expect them to include. So what happens people have to drop the powers they find really fun just to make their 'guild' happy so they can be productive on a team Skill based squashes all that. You build the toon you really want to be. Non-combat professions become totally viable. In old school SWG-pre CU/NGE, you saw a ton of non-combat professions where players really built the avatar the really wanted to be rather then being forced into a linear treadmill dictated by the Game designer into cookie cutter roles we have seen in a lot of MMOs at this point. All the MMOs are trying to innovate their class based systems but they all still end up with holy trinity- Warrior, Healer, and Mage. Sandbox / Skill based MMOs totally escape all that madness. We are not forced along some hardcoded chaarcter progression in a Sandbox like eVE. We can pursue the careers we really want to be. PRovides so much rich gameplay and experimentation Classes still provide guidance. But we can provide Guidance as well by asking the Player what type they want to be and suggest skills they should pickup. Classes make it easy too easy to turn away players. Its a sort of elitism we see. I know my friend that plays World of Warcraft poor guy he has to always respec his character to please his guild. I suppose some gamer's love the tight control Game Developers have over their characters but I've seen it too much for a game that is supposed to be infinite. Classes reach dead ends Good points you have but I think if a developer really wants to stand out they should go more freeform it has really paiud off for EVE. But if you have a huge budget and a good Intellectual property I suppose you can borrow bits from World Of Warcraft and of course still be popular