• Content count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About Fes

  • Rank
  1. Graphics Question from a Novice

    Huh. I personally would rather say that this is not a common thing but rather a very advanced. Let´s just say - if it were that easy to model a character, 3D-artists wouldn´t bother with Z-Brush & Co. anymore. ;-) I think I have an idea though how this could be made possible more easily. If I´ve understood you correctly, this is for a 2D game. So question would be if you wanted threedimensional characters with a volumetric mesh, or if it would suffice to have a flat mesh that would only have the (2D) form of what the player draw. In the latter case you could leave out all "different perspectives" stuff and just stick with your twodimensional projection. You could then perhaps use a system where the player has to mark the different bodyparts of his character, perhaps by just filling them with a certain color after he has drawn the outlines in the same color. So the computer would know that everything that is e.g. red is the characters head, everything blue is his arms, everything green is his neck, etc.. You could then go and let the computer sort out which were the biggest contiguous masses of a certain color, and use that respective masses as the bodyparts. You probably would need to ask the player to clarify - say you would expect two big contiguous masses for the legs and someone painted the legs so that they would touch and would be read as only one mass, the player would have to clarify where this mass would have to be cut in half to get to the two masses that form the two legs. And of course you would have to think about how to handle configurations like two heads, four arms, only one leg, etc.. But say you would have that sorted out and would have your algorithm to get to the point where the computer knows which part of the painting is what bodypart. You could then go up (or down, or whatever) the picture, line by line or probably rather every 5 or 10 or 20 lines, and look for an intersection with the respective bodyparts outline. This intersection would mark the first vertex, the second intersection (hitting the second outline or leaving the inside of the bodypart respectively) would mark the second vertex. This way you could then construct your mesh by connecting these vertices, although this in reality would be a lot more complicated then it is just sketching the idea. ;-) This would leave you with a set of flat meshes that you could connect and animate, texture and light in the engine. You could of course even just take the picture that the player drew as the texture of this mesh. And you should even be able to construct a very simple volumetric mesh, or at least a protruding mesh without a backside, basically using kind of a heightfield - if you got your two vertices resembling the boundaries of a bodypart on that line on screen, than you could create new vertices between those two points (perhaps based on a cosine function or something like that), more points when near to the edge, less when nearing the mid of the bodypart, gradually moving outer points back on the z-axis. This in practice could prove pretty tricky though. Especially I´m thinking of the intersection-algorithm - when you got bodyparts that wouldn´t be aligned orthogonally to the axis that you use for your intersection test, you would get really bad results, so you would have to automatically adjust your reference-axis. You probably should go look and learn more about triangulation (this could be a start: http://en.wikipedia.org/wiki/Delaunay_triangulation ), cause it could be real tricky to work out the details even for my suggested simple form above. And of course, if you wanted to take the mesh to 3D as written above, this would result in only a rough approximation that probably wouldn´t even be acceptable at all.
  2. BRDF confusion

    I do understand that this topic is a bit confusing, it is for me too. Wikipedia "coverage" on this topic is pretty sparse, this article http://en.wikipedia.org/wiki/Bidirectional_scattering_distribution_function mentions some of the other modells though. As I see it, definitions get a little blurry here. Basically a BRDF could give you specular shading or diffuse shading only, but it can also be composed of several components. Ashikhmin and Shirley for example proposed a BRDF that consists of a component that evaluates specular lighting and links it to a simple component for diffuse lighting, so that the amount of diffuse lighting diminishes as the amount of specularity gets higher. Other BRDFs like Oren-Nayar, Minnaert or simple Lambert modells only provide diffuse lighting, while Phong and Blinn for example may only offer specular lighting. (like DarkChris showed here) BRDFs can be combined of course, so you can have an object with a Lambert shader for diffuse lighting and a Blinn shader, or Ashikhmin-Shirley highlights (leaving out the diffuse part of the model) on top of a model that is diffusely shaded by a Oren-Nayar shader. (like DarkChris practically also showed) On the other hand a BRDF normally only cares about reflectance, that is the light bouncing of the surface, and doesn´t take into account light that enters the object/material; this is where e.g. BSSRDFs kick in. This more complex type of model also takes into account the light that enters the object and computes how it leaves the object, where it does and with what properties. This way you can achieve subsurface scattering which... well... describes how light is scattered under the surface of an object. ;-) With this SSS you can more believably visualize things that are diffusely translucent like milk, wax, etc.. On the other hand the Hapke-Lommel-Seeliger shader for example (used for shading powdery surfaces like, originally, the surface of certain moons) is considered a BRDF even though it incorporates a (comparatively simple though) method of calculating the amount of light that enters the surface and how it distributes and leaves the surface, hence a simple subsurface scattering term. That´s why I wrote that imho these definitions are a little blurry. So just don´t mind being confused. For todays game design most of those BRDFs have little relevance anyway, often being awfully slow to compute; the most basic ones, like those posted by DarkChris, excluded.
  3. RPG rules / mechanics / balance

    [quote=IADaveMark]Something can be 5x as strong if you make it 5x as expensive [/quote] I guess the problem here ist to judge how strong that something really is. Sure, you can build an extremely complex algorithm to judge how much e.g. an ability that increases a characters speed enhances it´s strength in combat. Judging how much players will want to have that ability simply because it cuts down time to move from one site to the other is not as easy though. Say you want to implement that "speed" ability and are going to assign a value to it, say, an experience point cost to level it. You will have to make decisions, such as "Do I want to give this ability away nearly for free because players desire it so much, or do I assign a heavy cost to it BECAUSE players desire it so much and will spend the XP on it anyway?". Your post was interesting to read non the less; seems like I have to learn more about game theory. [b]@Wrathnut:[/b] I don´t know the first edition D&D Books but I have found some (A)D&D publications to be quite good when it comes to such things. The TSR-wrought "Alternity" roleplaying system, published not long before they were taken over bei WotC, often offers really nice ideas that are clearly structured; such as different FTL drives, Weapons, Ship types, etc. per technological development level. However one thing that those books, and almost certainly also the old D&D books, don´t offer is perfect balancing for a computer RPG. Simply because it is not necessary there, nor does it even have to be wanted. In a pen&paper RPG you have the gamemaster to judge on a case by case basis, in a computer game you can´t do that. So when TSR published the Player´s Option books which allowed you to practically build your own character class by choosing from a list of abilities, the authors explicitly covered the topic of onesided powergamer charakters and both appealed to the players not to build such characters as well as to the GM to be wary not to accept such characters. For a computer game on the other hand you need definite rules because no GM is there to judge the situation. Now what WotC did with D&D 3rd Edition and especially D&D 4th Edition is to mitigate exactly those problems that arose of the necessity of the GM to individually judge a situation. I have one exact example for this. The disintegration spell had been with (A)D&D for a long time and so also appeared in D&D 3.0. The rules for this spell said that it would disintegrate a certain volume of material, be it inanimate or living. This made this spell into practically the deadliest spell in the game, because you would just assume to disintegrate vital parts of an enemies body, theoretically even being able to disintegrate part of a dragons head and at least causing loads of damage. But there trouble arose, because normally you could count that spell as a special instantdeath spell, but under some circumstances it would not mean instant death for the victim, because, say, the dragon´s head was so big that even the several dozen liters of disintegrated volume would not necessarilly kill it. And the spells description offered no measure of how much damage this spell would do to a victim that was not instantly killed, so it was totally up to the GM how much damage that would be or when a victim would be completely disintegrated. So when D&D 3.5 came out WotC would go and change the rules of the spell to "does 40W6 points of damage" (or so) and only disintegrating a victim if all of it´s hitpoints were diminished. Now I guess I would put it like that - you can mathematically balance the figures but you can´t mathematically balance fun. D&D 4th Edition shows what can happen if you try to hard to "get your rules straight". Previous editions had featured certain sub-rulesystems for e.g. spellcasting, but now those systems were "balanced" out and by doing that lost much of their appeal. Now every character class had loads of special abilities, and because there were so many of them, they all somehow seemed to be pretty much alike. They, too, lost appeal. So for effectively balancing a game you also have to take into account how things affect the player, how much fun a certain rule or element is, etc., and that won´t be done by following a guideline or relying on mathematics. Cause in the end balancing only serves the purpose of making the game more fun, and a mathematically balanced build that is no fun to play contradicts that. I however know of a book that covers RPGs, and it even is freely available as a pdf. It´s called "Design Patterns of Successful Role-Playing Games" and is written by Whitson John Kirk III. You can find it here: http://rpg-design-patterns.speedykitty.com/doku.php I personally only had a short look at it, because it was to analytic for me. It did seem like a pretty thorough work though, with it´s over 260 pages and lots of graphs, so give it a try!