WinFX Beta 2 - ScreenSpaceLines3D: where did they go?

Question

As the subject states:

WinFX Beta 2 - ScreenSpaceLines3D: where did they go?

I really like the speed of beta 2 but this is holding me back now...

Thanks

Answer 1

This feature is not slated for V1.

Answer 2

Are you serious?!

If so, do you have any suggestions how I should continue with my 3D editor:

http://blogs.infosupport.com//images/blogs_infosupport_com/ernow/151/o_Screenshot2.jpg

As you can see I need a replacement. I thought about reflectoring the old CTP ScreenSpaceLines3D but soon found out they are dependent on some serious internal classes...

Any suggestions? Please?... I'll beg if I need to...

Answer 3

Seriously this is a huge blow to WPF's 3D rendering capabilities.

I've been trying to implement Cubic Splines in 3D using WPF, but haven't been sucessful. I did a little research around ScreenSpaceLines3D as I thought I could gain some insight in how to implement them. Unfortunately ScreenSpaceLines3D are dependent on System.Windows.Media.Composition.DUCE, which is just a wrapper for milcore.dll, yet another wrapper for native code.

It seems like this functionality will have to be implemented using DirectX directly or OpenGL. Is it possible to include a native or managed DirectX surface inside WPF? (Or even interact with the one WPF creates?).

Thank You,
Cathode

Answer 4

As far as I know the rule is that a pixel must be owned by a single technology (GDI, DirectX, WPF) so mixing them up can only be done by using the CrossBow stuff that allows a part of the display in one technology to be rendered by another...

 

I don't care that DUCE wraps some native stuff the trouble is that everything that I need to rebuild all things that are marked internal if this is what it takes to get my Lines back I'll go there but I sure don't like it...

Answer 5

I'm in a similiar position.  I'm developing a simple game and I was relying ScreenSpaceLines3D.  If anyone comes up with a workaround, I would love to hear about it.

Answer 6

Things I have thought of so far:

1. Reflector the old bits and build my own ScreenSpaceLines3D class
• Cons:
1. Lots of work
2. Lots of hard work
• Pros:
1. Compatiblity with previous CTP's and (hopefully) with future releases
2. Use ordinary triangles but with a special materialbrush that only draws the edges
• Cons:
1. Different API from previous CTP's
2. Must use backface material in order to get the lines to show up from all points of view
3. The lines will not have a screenspace thickness
• Pro's:
1. 'Easier' to implement with the current API

So I'll give number one a shot tonight and see what problems I get into.

Wish me luck and if you have any suggestions: Let me(us) know!

Answer 7

Hi Erno -

If you like, you can use the ScreenSpaceLines3D sample I am working on in the 3D Tools for the WPF workspace as a starting point.  I have not yet built a release of the project for Beta 2, but you can grab these 2 files out of source control and incorperate them into your project:

    ScreenSpaceLines3D.cs
    MathUtils.cs

There are currently three known issues I am still working on:

1. You need to set your camera's FarPlaneDistance to something reasonable (like 10 or 100) rather than the default value of +Infinity.
2. It will do funny things if the lines penetrate the camera's projection plane.
3. If your lines are sufficiently wide that the segments you might see "bright spots" at the overlap.

These three caveats are well understood problems.  I can give you more details if your interested.  If I find some cycles this weekend I'll try to address #2 because it does not have a good work around.

Thanks,
- Daniel [MSFT]

PS - AnimationStudio looks very cool from the screenshots, BTW.

----

All postings are provided "As Is" with no warranties, and confers no rights.

Answer 8

Daniel,

Awesome! I quickly scanned your code and I must say that I am quite concerned with the expected performance but I'll give it a go.

Thank you so much for sharing!

I'll let you know what results I got.

Erno

Answer 9

Ok! After some experimenting:

My grids are working! Great! (Although I really miss the Bounds property that used to be available on the SSL3D...)

My models (3d wireframes) are not working. Here's why:

I use databinding to bind my views to a single model which provides the lines of the wireframe. The brand new ScreenSpaceLines3D inherits from ModelVisual3D instead of the old SSL3D that inherits from Model3D. I used to add a single Model3DGroup in my XAML and bind its Children property to the wireframe data. Now this won't work anymore because a ModelVisual3D cannot be a child of a Model3DGroup.

So I am stuck for the moment...

BTW: Performance isn't bad either! And so far I haven't run into one of the known issues (but hey, I'm only showing grids  )

 

Any suggestions?

Answer 10

Hmmm...  Heres my first idea:

ScreenSpaceLines3D.Points is a DependencyProperty.  Maybe you could bind/set the Points property of multiple SSL3D instances to a shared Point3DCollection?

Thanks,
- Daniel [MSFT]

----

All postings are provided "As Is" with no warranties, and confers no rights.

Answer 11

The problem with this solution is that the collection of SSL3D instances changes all the time. I add and remove SSL3D instances whenever the model changes... Binding to the Point3DCollection will not fix that. I need a ModelVisual3D collection thingy or I need to rethink my solution.

Thanks Daniel for thinking with me!

Answer 12

Ah.  That’s a tough problem.

You can group Visual3Ds (ModelVisual3D has a Children property), but you currently can not share them between Viewport3Ds to generate multiple views.

…and if there was a feature which allowed the visuals to be shared, that wouldn’t work in this instance because each SSL3D contains geometry that was uniquely widened to create the illusion of constant thickness with respect to the specific camera angle of the hosting Viewport3D.

I can really only think of two solutions, and both are a little more work for you than I would like.

1. If your “structure” is fairly static (e.g., you always have 2 SSL3Ds per Viewport3D, one for the grid and one for the model itself) you could replicate the Visual3D tree per Viewport3D, but share the Point3DCollection as mentioned above so you are still only operating on one data set.
   
2. Alternatively, you build a light weight data model which knows how to translate itself into a tree of ModelVisual3Ds.  Your editor manipulates your data model which in turn update the four visual trees on your behalf.

In fact, #2 is similar to the way FrameworkTemplates work in the WPF.  It is conceivable that you could use templates to create the 4 views from a single template of a Viewport3D with a databound Camera, but templates are not really designed for dynamic scenarios so you would have to fight the system a bit to get it to work.  It will probably be easier and faster to write your own data model.

Regards,
- Daniel [MSFT]

----

All postings are provided "As Is" with no warranties, and confers no rights.

Answer 13

Yes, you are right. I read and reread your code and I think I understand what you are doing.

My plan is this: The model has triangles (including points) and I will bind a single SSL3D per view to these points. And now the magic: I am going to rewrite (extend) your SSL3D code in such a way that it generates the lines for the view based upon the triangledata and it will allow me to specify several line segments each having a color and thickness. This way the model only knows about triangles and the SSL3D will be know henceforth as Wireframe

I'll try not to ruin your code too much so when you update yours I will be able to update mine :) I'll e-mail you if you're interested and notify the forum by posting.

 

Thanks

Answer 14

Hi,

 

I am facing the same problem usin SSL3D. I am working on Fluid Dynamics using WPF. I have used SSL3D but now as it is not supported in Framework I m using 3D tools for WPF (3dtools.dll). But as the new SSL3D inherits ModelVisual3D instead of Model3D i am getting error. Is there any way I can resolve this problem?

 

Thanks in Advance,

 

Chandrak