Early C# Port

[GoogleCodeExporter]

Early C# Port

[GoogleCodeExporter]

Cool!

We would be more than happy to host your port here when you feel your code when 
your 
edges get smoother ;). You would get your own Mercury repository separate from 
the 
other ports.

Feel free to ask anything about the code, you can use the email in the java 
code.
Yes the code base is a bit from a 1.0 release but I think its pretty nice for a 
first release. All suggestions for streamlining the API are welcome! I have 
kept 
some dead code and stuff in the code base since I did have some idee's for 
improvement.

Original comment by [email protected] on 17 Feb 2010 at 7:59

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

I added the link to your C# port on the Poly2Tri front page. I downloaded and 
tried 
your port :). I had to add System.Globalization.CultureInfo.InvariantCulture to 
LoadDat to get it to run on my computer. Appart from that it looked great!

Just one thing I noticed and that was that the triangulation of the example 
with 
10000 points seems to take much longer than my java implementation, 200ms 
instead of 
50ms.

Original comment by [email protected] on 25 Feb 2010 at 7:59

[GoogleCodeExporter]

I assume you're using InvariantCulture as the second parameter to the 
double.Parse calls?  I'll add this to the ExampleData 
project.

The 4x slowdown is roughly in line with what I'm seeing.  Using SlimTune I've 
been able to see that what seems to be taking 
the most time seems to all involve my FixedArray3's indexing operator ().  
Sadly, switching to more 'native' containers 
(arrays, List<T>) only worsens performance.

I'm suspecting that a large part of this is also GC (which SlimTune doesn't 
give profiling information about yet), given the 
rather large fluctuations.  On my system, I get in the range of 110-200ms (with 
Release x86 settings), and in the "Debug" 
project you can see it chewing through GCs like a madman -- understandable 
given that I am completely reallocating every 
object from scratch for testing.

I have some thoughts on speeding it up, but first, a disclaimer:  Triangulation 
at this point is fast enough for my own purposes, so speeding it up further is 
not a huge priority for me at this point.

That said:
1)  SlimGen.  Some of the guys working on SlimDX are playing around with 
injecting native code into .NET apps.  Assuming it 
ever becomes usable, I plan to apply it to some of the biggest performance 
bottlenecks.  This probably won't happen anytime 
soon, though.
2)  Object pooling/reuse.  I'm generally wary of this as it can often outright 
hurt performance, but having the option could 
help for extreme circumstances like the stress test goes through.
3)  Switching to large arrays of value types.  This would eliminate the ability 
to derive from TriangulationPoint to add your 
own data, though.  Such a change would probably go hand in hand with 
integrating SlimMath (another SlimDX offshoot), which 
would also automatically benefit from any eventual release of SlimGen.
4)  General optimization -- the code came with some comments about IndexOf 
calls that could be avoided, and I'm sure there's 
more lurking in the code (and even more indirect calls).  After a few 
graphics-related functions, the two highest function 
calls in my profiling list (by Time spent in them) are FixedArray3[] (~4% of 
total), and FixedArray3.IndexOf(T) (~4%) -- 
which calls the former.

So, there are certainly ways to improve performance.  By how much, though, I'm 
not sure.

Original comment by [email protected] on 9 Mar 2010 at 6:31

[GoogleCodeExporter]

Oki. I'm a C# novice myself :). Just wanted to make you aware of the 
performance 
differences.

Btw. I have noticed that the triangulation with the C# code isn't exactly the 
same a 
the Java/C++ versions. 

Compare the bird in these two sceenshots. 
http://java.poly2tri.googlecode.com/hg/resources/screenshots/quad_screen_02.png
http://github.com/MaulingMonkey/poly2tri-cs/raw/wiki/screenshots/bird.png

My first guess was that the basin code didn't work as it should but couldn't 
see 
anything wrong by just looking at the C# code. Could be some issues with the 
legalization that should make sure that all triangles are Delaunay. But I guess 
for 
just getting a triangulation that isn't so important :).

The last model in your screenshot is not a valid polygon( points aren't ordered 
). I 
added that for another example and it needs some ordering of the points to get 
a 
valid polygon for triangulation.

Original comment by [email protected] on 12 Mar 2010 at 11:18

[GoogleCodeExporter]

Btw. If you want you could host your code here and get your own Mercury 
respository.

Original comment by [email protected] on 13 Mar 2010 at 5:59

[GoogleCodeExporter]

The birds diverge because I flip the actual data before triangulating it to get 
things oriented right, rather 
than flipping it after the fact during rendering.  I double checked this by 
replacing 'true' with 'false' (e.g. 
no flipping) on ExampleData.cs line 71, and then flipping a screenshot in 
Paint.NET (attached) -- I then get 
identical results to the Java version (at least in the upper right tail, which 
is where I noticed the 
difference).  I believe both are valid triangulations, just caused by either 
the different winding direction, or 
by sweeping from the opposite end first, rather than a triangulation bug.

I do still need to fix the data loading of Strange.dat though, yeah.

At this point, I think I'll just stick with my github repository, unless 
someone asks for a Mercurial option.  
Despite git being rather unpolished (at least on windows), it's still my 
favorite SCM for some reason.  I 
daren't ask what that says about my sanity :).

Original comment by [email protected] on 13 Mar 2010 at 3:14

Attachments:

• unflipped-bird.png

[GoogleCodeExporter]

Closed!

Original comment by [email protected] on 15 Dec 2010 at 5:52

• Changed state: Done