Jump to content
  • Advertisement

David Neubelt

Member
  • Content count

    269
  • Joined

  • Last visited

Community Reputation

866 Good

About David Neubelt

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. David Neubelt

    Questions on Baked GI Spherical Harmonics

    For the figure on page (18) it was generated with SH9 baked into light map texels. However, you're approach with a grid will work as well if it's dense enough.The occlusion will come naturally and there are no additional techniques you need to apply because at every position in shadow the cubemap will receive less light.   This works for both diffuse and ambient.   I suspect the reason you aren't seeing any occlusion is because you are adding an ambient term artificially flattening out the scene.     If there is a bright light on the opposite side of the probe then yes. Ringing can occur when you have a bright light on one side which causes that side of the probe to generate really high numbers. On the opposite side of the probe facing away from the light it will need a really high negative number to counter act the high number.    The negative numbers are the cause of the ringing
  2. 1) To uniformly distribute the basis vectors - you can choose any distribution you want but that is just the one we went with.   2) Yes, the free parameters you want are the sharpness and amplitude.   There really is no rotation its just use the lights direction vector.   -= Dave
  3. David Neubelt

    Why You Shouldn't Be Making an MMO

    Here is another point of view from another guy that made a real MMORPG. [url="http://duatiu.blogspot.com/2011/05/duatiu-faq.html"]http://duatiu.blogspot.com/2011/05/duatiu-faq.html[/url] -= Dave
  4. David Neubelt

    Principles of Software Engineering

    Quote:Original post by Emmanuel Deloget Second question: why should this single instance be global? the only reason I see is that you need to access this instance from everywhere in the code - that's typically a good sign of a common design flow - a locality problem. I don't know anything which have to be global and used by all the services of an application. Or, to be more exact, I know only one thing: system resources. And global system resources are best used using functions, because the system is supposed to know about their state internally. If these functions need some id (representing an instance of something) to work, then this is not a global resource, since providing two different id will have a different result. So this cannot be represented by a singleton, as the id might change. If there is no intrinsic data to store, then why using an object? A function is going to do the job just as correctly. I'd like to quickly address your second question. Quote:Second question: why should this single instance be global? I am not going to argue that allowing a variable to be global across an application is bad design. I also believe it is bad design. I'm arguing that you can have global variables that are exposed to one module and only one module. In this sense, it is local to that module but global across all files in that module. There are two points we can argue here a) the effectiveness of a global variable and b) the single instance of an object. I'm sure we can both agree the advantage of a global variable in a library. Let's focus on the single instance of an object. Problem domain for single instances of objects If you are writing a module that needs to handle a system resource then I disagree on your view that a function call will always be the best idea. Imagine that the system resource gives you ownership of volatile variables. Having multiple access to these variables can cause system crashes and to protect your design you limit the entry point to those variables. This type of hardware implies the code has to control the state of the hardware. In this type of system there can only be one variable that controls the hardware and you must model your design with this restriction to protect against system crashes. You say that all systems should know their state internally by function calls but this just simply isn't true. I'm currently working on hardware that forces you to create a variable for the OS to use (they have it externed) and then make changes to that variable! There isn't always a fancy OS to hide all the details for you and for certain consoles there is a close one-to-one mapping of hardware state and variable state. I suggest for this domain of problems: * Wrap the volatile state of the OS in a class. * Only allow a single instance (single entry point). * Allow every file in the library access to that class. -= Dave
  5. David Neubelt

    Principles of Software Engineering

    Quote:Original post by Promit Here it is. A first round of Promit's Principles of Software Engineering. I may expand on this list in future posts, but this will get us started nicely. 1) There are no legitimate uses of the singleton design pattern. I disagree. I believe that in most situations you may have encountered that the implementation of a singleton on a class has been a bad design. I do not feel that the pattern in itself has no legitimate use. I'm only talking about the unique instance of the pattern and not the other properties. I'd like to draw a comparison, give reasoning and finally provide an example. First, I believe the pattern can be applied on objects as a modifier, much like the constant modifier. The implementation should not force the object to have all classes always have one instance but rather it should modify the class. For this program, my design says that having more then one instance of the class would be erroneous so let me mark it as having only one instance. Anything more would result in an error. It is a protection scheme much like statically typed languages. For another program, it would be acceptable for this class to have multiple instances so I would not mark it as a single instance. In an ideal language it would look like this class MyClass; // <-- declared MyClass = single // <-- in an implementation file somewhere else In C++ I've created a similiar construct that isn't as ideal. CGlobal<MyClass> inst1; CGlobal<MyClass> inst2; // second instance is the same as the first Notice, that in another program I could decide to use a second instance by not using CGlobal and another class. This allows me to decide on a per project basis or even per library basis of whether it makes sense to mark the class as having one instance. The point I'm getting at is that in certain domains having more than one instance is erroneous and any constructs we can use to enforce the design will be a step in the correct direction and lead to less buggy code. By allowing a choice of having multiple instances or single instance the design pattern creeps between the line of a singleton and multiton. Which gives it a more flexibility then it was originally designed. It makes sense that any class that encapsulates physical interaction with devices on a system that you will want to have one copy of that class. Imagine that this class will be managing interactions with physical devices that only allow control of a volitle variable through one thread. Anymore attempts to access that variable will cause a system failure. Also, imagine that this certain instance of this class needs to be seen by one module. By design: * This module needs only one instance of the class any more will result in a hardware failure. * The class needs global view from every other file in that module. Solution: * Protect the hardware by enforcing a singleton design on the class. It can manage state of the device and prevent any attempts to misuse it. * Perhaps, on another console you can have multiple access to the device so do not enforce that the class always has to be a singleton. This should be a modifier for that particular class in that module. -= Dave
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!