XNA Framework Content Pipeline

Re: questions on the default ModelProcessor

wachichi — Mon, 24 Sep 2007 02:24:45 GMT

Excellent! I found the first solution on the train, I guess the more answers you get from a forum, the less you try yourself ;)

Thanks for all you posts, they really helped me out and now I finally got my proof-of-concept working!

Re: questions on the default ModelProcessor

Shawn Hargreaves — Sun, 23 Sep 2007 19:00:24 GMT

If your object contains any graphics types (vertex buffer, effect, texture, etc) you can look at their GraphicsDevice properties
to find the device.

Alternatively you can look this up and store it from inside your ContentTypeReader. Look up ContentReader.ContentManager.ServiceProvider, query that for an IGraphicsDeviceService, and look up the actual GraphicsDevice from there.

Re: questions on the default ModelProcessor

wachichi — Sun, 23 Sep 2007 17:35:50 GMT

okok I know you must be bored of my questions by now, but I get the feeling I'm getting there ;)

to load and render a Model, you don't have to specify the device anywhere. However, when rendering primitives, you always need to specify the device.

So... in my example, i'm loading an object through a ccp. Now, I want to render this to the screen the same as when rendering a Model: using a simple myObject.Draw() call, without having to specify the device.

How can this be done?

Re: questions on the default ModelProcessor

wachichi — Sat, 22 Sep 2007 10:57:10 GMT

OK thanks again, I was already looking at the basicmaterial content, but didn't hope it would be deserialized into a basiceffect immediately. Thanks again!

Re: questions on the default ModelProcessor

jwatte — Fri, 21 Sep 2007 20:54:17 GMT

Good start! Now if you can get that table into the documentation on MSDN.

Also, I think you're missing the bone and node content types, and a diagram showing how they go together to create a model (I'm away from my reference -- is there a ModelContent ?)

Re: questions on the default ModelProcessor

Shawn Hargreaves — Fri, 21 Sep 2007 19:57:50 GMT

Funnily enough, I just finished the doc for a sample showing how to make a custom replacement for our Model class, which includes this table:

Design-time type	Run-time type
VertexBufferContent	VertexBuffer
IndexCollection	IndexBuffer
VertexElement[]	VertexDeclaration
TextureContent	Texture
EffectMaterialContent	Effect
BasicMaterialContent	BasicEffect
CompiledEffect	Effect

I'm sure I missed something, and we could certainly use a lot more documentation in this area, but that covers at least the most important types.

Re: questions on the default ModelProcessor

jwatte — Fri, 21 Sep 2007 19:14:18 GMT

I don't think the documentation is very clear on what the different content DOM classes are, and how they relate to the runtime content types. A diagram of some sort, with reference arrows, would help a lot!

Re: questions on the default ModelProcessor

Shawn Hargreaves — Fri, 21 Sep 2007 12:33:13 GMT

wachichi:

Now I can't figure out how to create a basiceffect in the reader ... or should I load a custom .x file? A Basiceffect would be a lot cleaner though ...

Two ways:

The way our Model class does it

Have a BasicMaterialContent instance in the content processor
Use writer.WriteObject to save this to XNB
In the reader, use reader.ReadObject<BasicEffect> to load it in
You can also use reader.ReadObject<Effect> to load the same data, which will give you back the data as type Effect, but the instance it returns will actually be a BasicEffect if the design time source type was a BasicMaterialContent

The manual way

Just call "new BasicEffect" in your reader, and then store whatever parameters you like into it

Re: questions on the default ModelProcessor

ShawMishrak — Fri, 21 Sep 2007 11:46:17 GMT

wachichi:
When creating a graphicsdevice from the default adapter, you need to pass in a pointer to a form... but this is not XBox compatible.

You mean the renderWindowHandle parameter of the GraphicsDevice constructor? On Xbox, you can just pass in IntPtr.Zero, since you don't have window handles on Xbox. I've successfully created GraphicsDevice instances on Xbox that work using this. I'm not sure if it's a "supported" or "recommended" way of doing this, but it works.

Of course, I would follow Shawn's suggestions in your content pipeline. This post is just meant to say that you *can* create your own GraphicsDevice instances on Xbox if you so choose. Just don't create a GraphicsDeviceManager as well!

Re: questions on the default ModelProcessor

wachichi — Fri, 21 Sep 2007 11:10:49 GMT

Thanks, thanks ... That helped me out again.

At least for 5 minutes.. I'm stuck again. Now I can't figure out how to create a basiceffect in the reader ... or should I load a custom .x file? A Basiceffect would be a lot cleaner though ...

Re: questions on the default ModelProcessor

Leaf Garland — Thu, 20 Sep 2007 05:37:58 GMT

The type is IndexCollection, not IndexBufferContent.

Cheers,
Leaf.

Re: questions on the default ModelProcessor

wachichi — Thu, 20 Sep 2007 04:51:03 GMT

Your answer solved most of my problems, but I cannot seem to find the IndexBufferContent class ... not even in the help file, while the VertexBufferContent was no problem at all.

Can you guide me on how to create an indexbuffer in the TypeReader?

Re: questions on the default ModelProcessor

wachichi — Mon, 10 Sep 2007 03:42:18 GMT

OK thanks for the extremely detailed answer, it actually makes sense ;)

I will try it right away.

Re: questions on the default ModelProcessor

Shawn Hargreaves — Sun, 09 Sep 2007 17:19:23 GMT

I'll answer 2) first, as that actually covers your question 1) as well.

The trick is, your ContentTypeWriter and ContentTypeReader don't have to implement the same type! The ContentTypeWriter has a GetRuntimeType method, which can report whatever type this data will be loaded into at runtime. For instance (contrived case) I could have:

    ContentTypeWriter MyWriter<string>
    {
        overrride void Write(string value)
        {
           output.Write(value);
        }

        override string GetRuntimeType()
        {
          return typeof(int).AssemblyQualifiedName;
        }
    }

and then at runtime:

    ContentTypeReader MyReader<int>
    {
       override int Read()
       {
          return int.Parse(input.ReadString());
       }
    }

Ok, so that on isn't particularly useful, but it gets the point across: as long as both the writer and reader agree as to what the format of the data on disk is, you can write one type, and then read that same data back into a different one.

This is not only how ModelContent -> Model works, but also how we handle things like VertexBufferContent -> VertexBuffer, IndexBufferContent -> IndexBuffer, EffectContent -> Effect, Texture2DContent -> Texture2D, etc.

There is never a graphics device during the build process, but instead it can use other related content types that do not require a graphics device. Then when this data is loaded back in, it can be read into the actual type that does use the graphics device.

There are two huge advantages to this separation of types:

It is much faster, since at build time we can store the data in simple managed types, not bothering to upload it to the graphics card as an actual GPU data type (for instance building large models is much faster if you don't bother to upload all the vertex data to the GPU each time)

Doing things this way makes it possible to build Xbox format textures and shaders, even though it wouldn't be possible to create an Xbox format GPU object on a Windows PC during the build process.

questions on the default ModelProcessor

wachichi — Sun, 09 Sep 2007 16:47:02 GMT

I'm playing around with a custom content pipeline, and there are 2 more things I would like to do before I get to the proof-of-concept level. I cannot find how to do it, but they should be possible as the default ModelProcessor seems to be capable of doing them.

Here we go...

1) In a custom typewriter, I would like to be able to access the graphicsdevice. A Model comes loaded with vertexbuffer and indexbuffer, so I know it should be possible as you need the graphicsdevice when creating a v-or-i-buffer. When creating a graphicsdevice from the default adapter, you need to pass in a pointer to a form... but this is not XBox compatible.

2) The default model processor generates a ModelContent object, but when you load a model you get a Model object! So somehow in the TypeReader it should be possible to do this conversion, but the different overloads of the Read method doesn't allow me to do this ... I always end up with some kind of violation.

Any comments/suggestions/ideas/thoughts ?