This project is read-only.

May I Contribute a Couple of Features?

Jun 16, 2008 at 11:37 PM
Edited Jun 16, 2008 at 11:37 PM
Hi again!

I am wanting to add some features to XNAnimation. Since my community game engine (Ox) uses it, I'd like to get my slightly more advanced lighting model working in it.

The first thing I'd like to change is to make point lights support DiffuseColor and SpecularColor instead of Color. It is pretty typical of lights to use two colors instead of one. The other thing I'd like to do is add support for rendering the model to a shadow map from a spot light. Lastly, I'd like to get fogging enabled on the model. I'd like to have all these features in the trunk as well as to avoid having to maintain a branch..

Would you mind adding me as a developer to this project so I can contribute some / all of these changes?

Please let me know :)

- Bryan
Jun 17, 2008 at 7:17 PM
Hi Brian,
Sorry for the late reply.

What you like to do is extend the effect used by the SkinnedModel. Today you can do that by changing the effect used by the SkinnedModel before rendering it but you cannot change its default effect (the one that is assigned to the model is processed). Right now I'm looking for ways to make the SkinnedModelProcessor easy to extend, and allow users to easily change the default SkinnedModel's effect. My idea is provide a combo box where users can select the desired effect for the SkinnedModel, and use reflection to find the user effects.

Right now the library is in its beginning phase, where its architecture is being defined and for that time I want to work alone on its core and has more control over it. But I also want to provide flexible and easy ways for developers to extend the library in any way they want.

I hope some of these ideas could come up in the next release. =)
Jun 18, 2008 at 1:34 AM
Thanks for the reply :)

First, I'd like to reemphasize my great appreciation of your work and the sheer amount of ingenuity that went into your system. I envy the skill you have in implementing the animation system as it is something I have never done. :)

But the matter I wish to bring up is what I perceive as the underlying flaw in XNAnimation's architecture that keeps it from being as flexible as we both want it to be. The flaw I perceive is the fact that XNAnimation encapsulates its XNA Effect objects. I'm sure your first reaction to wonder how I perceive this encapsulation to be a flaw. We are both learned to encapsulate everything as a matter of course! Has this been but a few months ago, I would have dismissed what I'm saying right now as being "undisciplined" :) But I am speaking about these things from my experience in correcting a very similar flaw in my very own code base! :)

In my view, the reason the Effect object should be public is because there is no single, complete way to encapsulate it while maintaining sufficient flexibility for end-users. The proper solution is to expose it directly, standardize the .fx files internal parameter variables, and allow the end-user to manipulate the Effect and add to/ change the .fx variables as he likes. While you may have good reasons for encapsulate the Effect, I assure you that there are more good reasons not to.

Similarly, I believe it does not make complete sense to generate the .fx from code. To put .fx into c# code is to take something that was once (and should be) data-driven and turning it into behavior that is hard-coded. Certainly you can see the loss of flexibility inherent in that! :) Now, I realize that the .fx files contain constants that are also unavoidably defined in c# code. I realize that you want to avoid duplicating these code definitions over the .fx file and c# code. But if you really want to avoid constant definition duplication, then you could have the c# code read in the constant from the .fx file itself via a little string parsing magic. Thus, it would remain data-driven and thus flexible enough to meet our goals.

Take, for example, the MD5 Model importer component. Now, I'm not saying it has a better overall architecture! But consider that all I have to do to make it match my engine's lighting model is to change the .fx file and the custom code I use to render it. Avoiding encapsulation of the Effect object and allowing the end-user to render it manually allows me to change all the things I need to adapt it however I like. What's more, I can easily make it render to a shadow map just by copying the original .fx file, ripping out most of the pixel's shader's guts, putting in the few lines of code to make it render a gray-scale, and adding just a few other tweaks. I refactor the C# rendering code and... voila! Shadows! :)

I am definitely not attacking the idea of encapsulation! It is the basic lesson taught to all good engineers. But what is not often taught is that every encapsulation imposes a roughly proportionate decrease in flexibility. So I'm sure you realize that it becomes a matter of weighing costs. One asks oneself - does losing flexibility cost me less than I gain from hiding implementation details in a certain context? If so, then the answer is clear :) But otherwise, you might be compelled to think twice, and my end up making a different decision which ends up to be more appropriate. :)

Thanks for taking the time to read all of that :)
Jun 18, 2008 at 6:22 PM
First, thanks for you kindly words about the project. =)

I'm not sure if I get your idea correct but what you want to do is maintain the effect completely separated from the model? Some of the things that you said are already possible in the current version of the library. The SkinnedModel class encapsulates an XNA's Model, which contains the vertex and index buffers that you need to manually draw the model. So you could just avoid any effect that was previously set on the model and just render it manually using your effects. Another option would be to just change the SkinnedModel effect right after it has been loaded. Although the effect is encapsulated you can change it for any effect, which could be loaded .fx files.

Thus, besides the model has an effect encapsulated you can just ignore it and use your own effects and shader management classes, or render it manually in any way you like. I can't think in a specific example where this encapsulation restrics what you can do because you can skip it. I hope it answers your fourth paragraph.

About the Effect code, I believe it is easier for the users to just have it compiled with the library assemblies. If the effects where distributed in separated .fx or xnb files it may cause a lot of confusion to the end-users. Also, the xna framework uses the same concept with the BasicEffect class, so some users may expect the same behavior from the SkinnedModelEffect class. But you have access to the SkinnedEffect.fx source file from the project source code page. Therefore, you can use the FX source code as a base to create your own effects.

>> Now, I realize that the .fx files contain constants that are also unavoidably defined in c# code.
That's true. One easy way to handle this would be to inject the compiled constant code in the fx code, or do as you said, just read it back using annotations. It is a good idea, thanks! I will add it to my task list but right now there are other important things that I have to fix in the library prior to this.

One of my ideas is to make the next content processor more flexible, letting you select which effect processor the SkinnedModelProcessor will use and providing a base SkinnedEffect classe to be extended.


Jun 25, 2008 at 7:43 AM
Cool man. Looks like I should have dug deeper into the component first :)

I'm going to see what I can do to make this adapt to my lighting model as close as possible :)