A few worries

Avalon has been exciting me for a long time now, but lately I've become a
little bit worried about a few things regarding WPF and the workflow.

1) 3D performance, Judging from ch9 videos, there seems to be some speed
performance issues with 3D rendering. Is it going to get significantly better
in the final release? Right now it seems to be outperformed even by old
technology such as Shockwave3D when it comes to pushing polygons. Are there
any benchmarks available?

2) Graphic designer workflow. I really don't like that you have to *export*
as XAML. That kinda goes against the whole workflow foundation concept IMO. I
should be able to save my design, edit some things with an external editor,
and just continue within the graphic designer. Exporting/importing each time
is not a very nice solution. What's the reason? What's the plan?

3) Interop with today's major graphic design file formats (PSD, SWF, AI
etc). Why aren't there any converters to XAML? That really is key to winning
over the design industry. And from what I can understand there aren't even
any plans on releasing such tools. Also see my comments regarding this at:
http://blogs.msdn.com/mswanson/archi....aspx#comments

Anyone have anything to share on these matters?

> Performance is normally the last part of the product cycle after feature
sets
> have been completed.

Sure, first run then run fast, but still it'd be interesting to hear some
kind of forecast. Say I'd like to help MS "getting stuff out there day 1" by
creating a killer app game now, then I would need some idea how it's going to
perform.


> Tool workflow [...]. You should talk to the
> company\group that owns your favorite tool and make sure xaml is as free
> flowing in both directions as possible. Be heard.

My "favorite tool" is Sparkle. It's pretty strange that XAML doesn't flow
freely through it.
As for Adobe tools, I can't see why they would want to support XAML
export/import. They have the upper hand ATM, and they should be thinking
desperately about how to keep XAML off their users' hands.


> There are some converters to xaml done by the community for a few different
> design packages

Have you got a list of links? I have yet to see a converter for any of the
big formats.


> and as WPF gets established there will be more of the
> official variety.

It would get established much faster if there were converters... I'd say a
few weeks of dev time from MS to create converters could correspond to
millions of dollars of ad costs, when it comes to adoption of the format from
the designer community. Once they've made the switch the converters aren't
that important anymore (when they understand how bad their old tools were).

Reasoning like "if it makes business sense, then it will be done" doesn't
work on me, I've seen too many examples of the reverse (both of them) being
true. I know I must make my voice heard not to the business people, but to
the community hoping to create enough buzz to make a change.

Performance is normally the last part of the product cycle after feature sets
have been completed. Thus, I expect performance to increase the closer the
bits get to the actually shipping.

Tool workflow has nothing to do with WPF at this point. Expression, aurora,
zam3d... is there, but no on knows final forms. You should talk to the
company\group that owns your favorite tool and make sure xaml is as free
flowing in both directions as possible. Be heard.

There are some converters to xaml done by the community for a few different
design packages, and as WPF gets established there will be more of the
official variety. But, again, talk to your tool vendor. If they don't think
there is demand, it won't get done unless it's done by the community.

In the end, for any new technology, there requires a push of faith by a few
to create a level of acceptance which creates leverage for a mandate.




"Jonas Beckeman" wrote:

> Avalon has been exciting me for a long time now, but lately I've become a
> little bit worried about a few things regarding WPF and the workflow.
>
> 1) 3D performance, Judging from ch9 videos, there seems to be some speed
> performance issues with 3D rendering. Is it going to get significantly better
> in the final release? Right now it seems to be outperformed even by old
> technology such as Shockwave3D when it comes to pushing polygons. Are there
> any benchmarks available?
>
> 2) Graphic designer workflow. I really don't like that you have to *export*
> as XAML. That kinda goes against the whole workflow foundation concept IMO. I
> should be able to save my design, edit some things with an external editor,
> and just continue within the graphic designer. Exporting/importing each time
> is not a very nice solution. What's the reason? What's the plan?
>
> 3) Interop with today's major graphic design file formats (PSD, SWF, AI
> etc). Why aren't there any converters to XAML? That really is key to winning
> over the design industry. And from what I can understand there aren't even
> any plans on releasing such tools. Also see my comments regarding this at:
> http://blogs.msdn.com/mswanson/archi....aspx#comments
>
> Anyone have anything to share on these matters?

Jonas Beckeman wrote:
> Have you got a list of links? I have yet to see a converter for any
> of the big formats.

http://channel9.msdn.com/ShowPost.aspx?PostID=87407

and a discussion:
http://blogs.msdn.com/mswanson/archi...30/519733.aspx

Cheers,
Dom

Thanks Dominic. Those exporters are definitely one step, but a file converter
is much more versatile. It can be used both as an exporter, as a stand-alone
app (for batching etc) and as an importer plugin inside of Sparkle. And
Photoshop and Flash are still missing...


"Dominic Willems" wrote:
> http://channel9.msdn.com/ShowPost.aspx?PostID=87407
>
> and a discussion:
> http://blogs.msdn.com/mswanson/archi...30/519733.aspx

Quake 2 could maybe be used as an example, as it already exists in managed
code. How would that run when on WPF instead of MDX?

I'm not really interested in how a specific example will be expected to run
though, but in knowing where the bottlenecks are, how big they are and if
they're going away. With that information I can conclude myself how different
aspects of a project should be implemented.


"TheRHogue" wrote:

> If you are writing a game, you will need to be more specific about the type
> of performance you need.
>
> Is it 2D - how many sprite animations will be running at one time?
> Is it 3D - how vertex points are will be in a scene?

If you are writing a game, you will need to be more specific about the type
of performance you need.

Is it 2D - how many sprite animations will be running at one time?
Is it 3D - how vertex points are will be in a scene?

"Jonas Beckeman" wrote:

> > Performance is normally the last part of the product cycle after feature
> sets
> > have been completed.
>
> Sure, first run then run fast, but still it'd be interesting to hear some
> kind of forecast. Say I'd like to help MS "getting stuff out there day 1" by
> creating a killer app game now, then I would need some idea how it's going to
> perform.
>
>
> > Tool workflow [...]. You should talk to the
> > company\group that owns your favorite tool and make sure xaml is as free
> > flowing in both directions as possible. Be heard.
>
> My "favorite tool" is Sparkle. It's pretty strange that XAML doesn't flow
> freely through it.
> As for Adobe tools, I can't see why they would want to support XAML
> export/import. They have the upper hand ATM, and they should be thinking
> desperately about how to keep XAML off their users' hands.
>
>
> > There are some converters to xaml done by the community for a few different
> > design packages
>
> Have you got a list of links? I have yet to see a converter for any of the
> big formats.
>
>
> > and as WPF gets established there will be more of the
> > official variety.
>
> It would get established much faster if there were converters... I'd say a
> few weeks of dev time from MS to create converters could correspond to
> millions of dollars of ad costs, when it comes to adoption of the format from
> the designer community. Once they've made the switch the converters aren't
> that important anymore (when they understand how bad their old tools were).
>
> Reasoning like "if it makes business sense, then it will be done" doesn't
> work on me, I've seen too many examples of the reverse (both of them) being
> true. I know I must make my voice heard not to the business people, but to
> the community hoping to create enough buzz to make a change.

You should use Managed DirectX or DirectX. WPF is not for games like Quake.

WPF 3D is for data visualization, UI, and model interaction. I do recommend
it for basic\simple games (puzzle games, card games etc...) as it is much
much easier to develop in than MDX or DX.

WPF's purpose in life is for creating richer business applications of the
future. Quake doesn't match very well in that arena

"Jonas Beckeman" wrote:

> Quake 2 could maybe be used as an example, as it already exists in managed
> code. How would that run when on WPF instead of MDX?
>
> I'm not really interested in how a specific example will be expected to run
> though, but in knowing where the bottlenecks are, how big they are and if
> they're going away. With that information I can conclude myself how different
> aspects of a project should be implemented.
>
>
> "TheRHogue" wrote:
>
> > If you are writing a game, you will need to be more specific about the type
> > of performance you need.
> >
> > Is it 2D - how many sprite animations will be running at one time?
> > Is it 3D - how vertex points are will be in a scene?

But why is it slow? For pure 3D (no vector gfx), WPF shouldn't have to be
much more than a thin managed layer around DX, something like the 3D engines
Irrlicht or Axiom, no? I can imagine WPF doesn't expose much of its inner
core, which makes project-specific optimization difficult - but even a fairly
generic 3D engine should be able to do Quake 2 at an acceptable framerate
with today's hardware.

Maybe it completely lacks optimizations like octtrees, but at least I should
have the level of control over rendering so that I can implement them
myself...

If WPF really is, and will remain, too slow, I hope that it will allow me to
"direct" the rendering to surfaces I have created myself with D3D, so I can
create the in-game UIs using WPF.
Otherwise, we'll start seeing 3rd-party WPF implementations (partial, of
course), just like we see with Flash when used for game UIs.

It would feel a bit like a waste of time to implement an alternative WPF. On
the other hand it would become a more cross-platform technology than the
downsized WPF/E.
When I started to get more facts on WPF, I thought it would make the game
devkit that I'm working on (http://codeproject.com/csharp/endogine.asp)
pretty useless, but maybe I should actually try and morph it into a XAML
renderer. Got my work cut out for me...


"TheRHogue" wrote:

> You should use Managed DirectX or DirectX. WPF is not for games like Quake.
>
> WPF 3D is for data visualization, UI, and model interaction. I do recommend
> it for basic\simple games (puzzle games, card games etc...) as it is much
> much easier to develop in than MDX or DX.

WPF 3D is not like Axiom or Irrlicht. WPF 3D is not just a wrapper around DX.

You can host D3D in a WPF app, but you will not be able to Overlay WPF over
it. This is a Version 2 feature. I know you didn't want to hear this.

One performance issue, currently, is that lighting is done in software. I
believe this will be fixed in Version 1. I think hardware support for WPF 3D
is aimed at the level of DX 7.

SDK blurb:

"The Windows Presentation Foundation 3-D implementation allows developers to
draw, transform, and animate 3d graphics in both markup and procedural code,
using the same capabilities afforded by the platform to 2D graphics.
Developers can combine 2-D and 3-D graphics to create rich controls, provide
complex illustrations of data, or enhance the user experience of an
application's interface. 3-D support in Windows Presentation Foundation is
not designed to provide a full-featured game-development platform."


Other perf issues are due to the robust compositional nature of 3D and 2D
living together as one...no simple wrapper here. For business apps, this is
really a break through on ease of use with 3D.

Now in Version 2, things will change somewhat as there may be a push for WPF
3D to reach DX 9 level, and that could make WPF more viable for you.


"Jonas Beckeman" wrote:

> But why is it slow? For pure 3D (no vector gfx), WPF shouldn't have to be
> much more than a thin managed layer around DX, something like the 3D engines
> Irrlicht or Axiom, no? I can imagine WPF doesn't expose much of its inner
> core, which makes project-specific optimization difficult - but even a fairly
> generic 3D engine should be able to do Quake 2 at an acceptable framerate
> with today's hardware.
>
> Maybe it completely lacks optimizations like octtrees, but at least I should
> have the level of control over rendering so that I can implement them
> myself...
>
> If WPF really is, and will remain, too slow, I hope that it will allow me to
> "direct" the rendering to surfaces I have created myself with D3D, so I can
> create the in-game UIs using WPF.
> Otherwise, we'll start seeing 3rd-party WPF implementations (partial, of
> course), just like we see with Flash when used for game UIs.
>
> It would feel a bit like a waste of time to implement an alternative WPF. On
> the other hand it would become a more cross-platform technology than the
> downsized WPF/E.
> When I started to get more facts on WPF, I thought it would make the game
> devkit that I'm working on (http://codeproject.com/csharp/endogine.asp)
> pretty useless, but maybe I should actually try and morph it into a XAML
> renderer. Got my work cut out for me...
>
>
> "TheRHogue" wrote:
>
> > You should use Managed DirectX or DirectX. WPF is not for games like Quake.
> >
> > WPF 3D is for data visualization, UI, and model interaction. I do recommend
> > it for basic\simple games (puzzle games, card games etc...) as it is much
> > much easier to develop in than MDX or DX.