comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Vector output of idlgrpolygon models
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Vector output of idlgrpolygon models [message #78341 is a reply to message #78273] Wed, 09 November 2011 09:27 Go to previous messageGo to previous message
Karl[1] is currently offline  Karl[1]
Messages: 79
Registered: October 2005
Member
I was going to point out that Select could be called for each pixel, but you figured that out :-).

But I also didn't point that out because I still don't think it is a perfect solution.

Did you actually send the resulting polygon list to vector output and inspect the results? I think that rendering the resulting polygon list to the display would look pretty good, since you're getting help from the depth buffer. But that won't be the case on a vector device.

If two of your surfaces (toroids) intersect, there are going to be some faces that intersect with each other.

EYE
|
V

\ /
\ /
\ /
^ \/
| /\
Z / \
X - - >

Your algorithm would (correctly) select both surfaces and put them both in the list to send to the vector device. That device is going to render then both in the order you supply them and you'll see one surface or the other near the intersection. The part of the second surface to draw that is behind the first drawn surface will draw on top of the first surface, which is incorrect.

But perhaps your data does not do this and you may be fine.

The GL2PS approach is very interesting. It uses the same technique that the IDL Clipboard uses (OpenGL Feedback buffer) and sorts things in a similar way if you pick the simple sort option. I had also mentioned using BSP trees and I note that GL2PS offers a BSP tree sort option. This would address the problem I illustrated above with the intersecting surfaces. These two surfaces would each be split at the intersection line, resulting in four surfaces. The two "back" pieces would not be in the remaining list and would not draw, leaving the two "front" pieces to represent the correct rendering of the intersection. Might still be worth a look if you need this sort of precision.
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: Vector output of idlgrpolygon models
Next Topic: random forest implementation in IDL

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:22:21 PDT 2025

Total time taken to generate the page: 0.00384 seconds