This project is read-only.

Xen Feedback / Questionnaire

Dec 5, 2008 at 12:45 PM
Edited Dec 8, 2008 at 8:22 AM

Two months ago today, I uploaded Xen 1.0 beta. Its had 500+ downloads in that time, which is fantastic!
I'm now looking for feedback on the future direction of the project.
I would like to know any thoughts you may have, positive, negative and what you'd like to see in future updates. Large or small, anything is greatly appreciated!

I'm interested in where you feel xen is lacking, what features you would really like to see, if there is anything holding you back - that sort of thing.

If you do not have a codeplex account, you can send me a message directly:


Thankyou very much!

Dec 7, 2008 at 2:35 PM

Xen is really great once you climb through tutorials and get used to it :-)
The only thing I'm dreaming of is a built-in fast particle system, everything else just doesn't seem important enough.

So, just to name a few of these unimportant secondary things out of my head: built-in quads/billboards, text billboards (typically nametags in mmorpgs, for example), built-in ability to capture screenshots, some ray-picking(or depth-buffer picking) and camera tutorial covering orthographic mode would be nice, maybe even default implementation of a standard arcball camera.

Model shader override mechanism is somewhat counter-intuitive, also it's kinda hard to find a InputMapper.MouseVisible property, so another tutorial maybe?
Just something to ramble about, with my unskilled hands DepthDrawSorter won't fork for quads ripped from custom geometry tutorial, postCuller.TryGetBounds always return false, so actual sorting won't happen.

Thank you for your interest)
Dec 8, 2008 at 8:36 AM
Edited Dec 8, 2008 at 8:38 AM

Hi Vigil.

Thankyou for your reply :-)

You will be pleased to know particle systems are on my short-list. However they are a tad complex, as runtime hotloading is critical when authoring fancy looking particle effects, and GPU support is also quite important on the 360. I'm still working out how feasible the latter is.

For the DepthDrawSorter, I'm happy someone is using it, even if it's not working :-). The sorter works by computing a bounding box from the CullTest performed on the drawable object - so if the CullTest implementation does not make any calls to culler.TestBox(), culler.TestSphere(), etc, then it won't have any data to work with. I added the ICullableInstance interface, so classes such as ModelInstance can be CullTested earlier (you can specify an instance world matrix). I'll also be changing it so it only calculates the average centre point, not the bounding box (which should be much faster)

I am also considering allowing the scene classes to be merged and used together, and I am also considering a class that loosely updates the camera Frustum (so culling would only occur when the camera moves/rotates beyond a threshold), I'd imagine this would help the xbox a good deal.

For the floating text above characters (this is what you mean?) this could be implemented with TextElements, using DrawState.ProjectToScreen() to work out where to place them.

I'd agree with you on your other points. Although I'll say some things won't change, no matter how much I dislike them now (eg, MouseVisible) :-) The last thing I want to do is make breaking changes. I've only had to do this once, with IDrawBatch, and that was because I forgot about it :-0

I would doubt you will see ray picking, as it's not something that I could see easily fitting into the current design.

Dec 9, 2008 at 8:52 PM
Edited Dec 9, 2008 at 9:05 PM

I also love XEN. Some of the stuff are made just incredibly easy to work with.

I would love to see Direct manipulation of animation bones as you have written is very likely to happen.
We will probably need to do such a thing in our project.

I would love to see more metadata comments on the classes. Sometimes I get lost I have no idea what some class
is for or a method in it. I am saying this because most people that use your tool will probably be learning to pull the ropes
as they do. The more info and explanations the better.

Our project is on freeze for two weeks due to final week approaching but we will resume it around Christmas break with full
power so I will be back bothering you ;) Hopefully by February we will have some prototype to show. 

Jan 1, 2009 at 11:29 PM
Edited Jan 1, 2009 at 11:32 PM

Perhaps you could add a MaterialShader that works with Shader Model 3.0. It could have more lights, support more bones,
and maybe use parallax or relief mapping in place of normal mapping. Not saying that you should replace the original shader, but suggesting you should add a second for more advanced hardware...

Jan 6, 2009 at 6:24 AM
Edited Jan 6, 2009 at 11:14 AM

Hi YellPika.

I did consider this, and when you run on the xbox it actually is using SM3, however vertex shaders in SM3 have the same register limits as SM2 vertex shaders, so more bones are not possible (without compressing them, which I considered).
The advantage would be more per-pixel lights (I feel 6 per-vertex lights is more than enough). However, this would be getting very expensive. Using two per pixel lights, with normal mapping and specular is 64 instructions. 4 lights without specular is actually cheaper (58).

My thinking, is that if I were to load up with a large number of lights it would simply lead to slow rendering for the of users who tried to use them. However, if you are careful, you can still have a lot of lights (upto 10 per pass!), and you can make some very complex lighting by careful mixing of per pixel and per vertex lights, and toggling per pixel specular in the material. There is nothing stopping you from doing this on a per-model basis too.

If you look at games such as Gears of war (or any UE3 based game), the majority of the time there is only one or two major light per character, usually with a secondary ambient or directional light. They sort what lights will have the most impact, and fade them in and out (you can see it happen sometimes, but the majority of the time, you'd never notice). They could have rendered every single light, however this would have been a performance disaster, and had little visual advantage.

As for parallax, etc, those effects I'm happy to leave to developers. They are horribly expensive and need to be used with subtly and care. I feel they require very specific tweaks and content requirements to look good (Something I can't provide). Given the option, a lot of users would probably just enable them, with little understanding of their significant performance cost (and their wildly varying system-to-system performance). MaterialShader is there to provide a good starting point, and something 95% of people will find useful. But there is nothing stopping someone creating a AwesomeMaterialShader either :-) And if someone did make one, it's the sort of thing I'd consider adding to Ex.

You can easily get into the 'one more effect' mentality. There are a number of other projects I could mention that take this approach, adding effect after effect. While I understand that way of working I don't feel it's a very productive use of time, as the majority of them will end up unused.

So... I do appreciate your feedback, but I feel what I've done is the a good balance.
I hope this doesn't sound like a cop-out....

Feb 7, 2009 at 7:53 PM
I guess you are still looking for feedback.
Well here goes: I only registered here at codeplex that i can leave you this message.
I find your work absolutely brilliant. It is very well designed, commented THE BEST in all the open source code i have read through ever.
It has nice, easy-to-understand tutorials very well grouped together and built on top of each other. Not many people take the time to do this, although in my opinion this is the single most important step to acquire happy users. Nobody cares if you make the new CryTek engine if nobody can use it without rocket science. This is especially true for a product that targets XNA. I mean XNA users tend not to be at top of the game development food chain.

I was just googling around a few days ago, no idea how i ended up here, but downloaded Xen and started to play with it. A week later now i have an exciting little project going. I already have some basic scenegraph for my own scene objects that implement your interfaces and use Xen game logic. I have a simple brute force terrain going with JigLibX integrated already for physics.
Physics integration was absolutely easy! I was going to do particles myself, but i am so happy to see that Xen 1.5 will already have them. Nice, less trouble for me :)

I am guessing i will try to get some dynamic shadows going next then.

Keep up the good work!
Feb 25, 2009 at 8:55 AM
Edited Feb 25, 2009 at 8:56 AM
Great work StatusUnknown!  We are lucky to have someone invest so much of his own time and precious hardware experience into evolving Xna.  Xen hits most of the sore points I've had with the Xna api.  I haven't had the time (or in many cases the architecture experience) to address these so I am very grateful!

Now I am only on a quest to resolve the scalability issues of the Xna Content Pipeline.  But that is a whole different kettle of fish. :)


Feb 25, 2009 at 11:16 AM

Don't get me started on the content pipeline... :-)

Thank you all for the positive comments. It means a lot knowing I'm helping out! :-) 

Mar 9, 2009 at 12:38 PM
I just wanted to echo hunharibo's sentiments. Xen is well designed, well commented, easy to read and easy to use. I was scratching my head about how to render efficiently with XNA so Xen has (at least in theory, right?? :)) taken care of that for me.

Getting my shaders to work with Xen was fairly easy, and was my biggest worry. Having the shader compiler pickup bugs early is very handy. Keeping the non-graphics API features in a separate library was a good move, and the additional modules within the Xen.Ex library is gravy.

Kudos and thanks for Xen, look forward to seeing what future additions may bring.
Mar 10, 2009 at 5:16 AM
Hello you did a really nice job on this library. A pretty neat demo and tutorial, I'm really excited to add it to my own engine. I haven't started working on it yet but I was concern about the thing that you plan to add.
Maybe you already said it before but I'll ask just in case. My first idea is to allow to draw onto a model's texture. This could be really neat for example for a cursor or bullet holes.

anyway keep it up !

Mar 10, 2009 at 11:59 AM

Hi sueds.

Unfortunately, that is exactly the sort of feature I won't be adding. 

There are a few reasons for this, the main one being it could be implemented on top of what is already there, it would be difficult (but no more difficult that adding it directly to the existing model classes).
It's something that is very game specific (I try and avoid adding things that have uses in only very specific cases to existing classes). It would have limited application outside of the example you give - and even in the bullet hole example, this is something that is *very* tricky to implement - and requires all sorts of assumptions about how the code will be used. It also adds a lot of overhead for the (vast majority) of people who don't use it (eg the mesh data needs to be kept in memory). Another example, simply detecting where the character was hit is very tricky, and app specific - let alone converting that point to the matching texture coordinate on the model's texture (even harder).
The actual process of rendering the model texture to a render target, and applying decals, and using that texture instead to draw the model is quite simple in comparison.

Sorry if I've disappointed you.

Mar 10, 2009 at 9:14 PM
I kind of understand your point, but I thought bullet hole could integrated in simpler way. Maybe through the pixel shader using a projection mapping with the depth transformation. I hadn't the time to look at this technique but it seems to me theoretically correct. Since you already develop a shadow mapping technique it wont be hard to integrate. But I guess maybe I could extend it by myself. But projection texture is a neat feature and can be sued in many different way, tio create decals which fits the lanscape or the geometry. But as I said I do understand your point of view just giving a random opinion.

Also I really loved the video, in fact your project really excited me, the fire demo is pretty impressive and the snow storm also. I though something way missing in the demo I've seen in the video, the particles demo. this one was one of my favorite. I hope you'll add a demo in your next release.

I haven't done the tutorial yet so maybe you answer my question in it but do you think the technique use in your demo to render decal could be use in the grass rendering ?
I guess yes but it could be a nice example to create also.

Anyway what you've done so far is just brilliant.

Keep it up.
Mar 12, 2009 at 10:49 AM
Edited Mar 12, 2009 at 10:52 AM

Hi sueds. Sorry for the slow reply. I've been thinking about the problem and how to reply.

About the bullet hole problem - I've been thinking at it from a few different angles, I always came to the same conclusion; There are several ways to implement the feature. And I think this validates my initial thought that it's something that is very application specific. The way an app stores it's data and renders has a significant impact. For example, the way I'd implement it for a deferred renderer would be totally different than a forward renderer.

One of the hardest things to do, when designing and building software is keeping an open mind to how the software would be used. There is a balance that has to be struck. The danger is if you go too far in one direction, those people using the code can get into a trap thinking that is the only / intended way to do something unintended.
A good example is the scene partitioning classes in Xen.Ex.Scene, these always had the design intention of only improving cull test efficiency (which they do), however a lot of people assume they are for things like collision detection. This is my fault, and while they could be used for that, they weren't intended for that use. The answer in such a case usually is that a game specific algorithm is the best option.

Things like particle systems are a bit different though, as their use is very clear. :-) In such a case it's more about the usability not what they are used for.
So I guess my final answer to the question is that you should do what is best for your game, and it's not something I feel I can really help you with. I'm just going to apply my own assumptions on the problem (as demonstrated in my previous reply).

As for the video, yes, the xbox stress test isn't included in the project (I was wondering if someone would ask :). I whipped that up for the video. It's actually a fairly simple effect (just a magnet effect, where particles are pulled to a global point, the closer they are, the more they get pulled). The tricky parts were getting the colours to look nice and managing the fill rate hit (if each particle is 1 pixel bigger, you are suddenly drawing 1,000,000 extra pixels! :) This is why at the end of the video, the frame rate drops off. The particles all bunch up, close to the magnet, so their velocity increases a lot - and suddenly the pixel rate spikes significantly.

Otherwise thank you for the positive comments :-)