POV-Ray : Newsgroups : povray.off-topic : kd-trees rule! Server Time
9 Oct 2024 14:33:29 EDT (-0400)
  kd-trees rule! (Message 13 to 22 of 32)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Invisible
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 09:25:51
Message: <499582ef$1@news.povray.org>
Warp wrote:
>   Kd-trees are indeed quite handy. They are eg. used in 3D games in
> certain situations where triangles need to be rendered in a certain order.
> 
>   For example semi-transparent polygons have to be rendered from
> farthest-from-the-camera to closest.

Ah yes, the "painter's algorithm".

Incidentally, while playing CSS the game engine appears to very 
occasionally get this wrong. (I.e., distant objects appear *in front* of 
nearer ones - typically textures for things like explosions, window 
glass, etc.) The result looks very weird.

>   Step in the kd-tree.
> 
>   If you add all the semi-transparent triangles into a kd-tree, you will
> be able to render the triangles from farthest to closest with a simple
> O(n) traversal of the tree, regardless of where the camera is
> with respect to the triangles. The comparison to be made at each node
> is much simpler than the comparison which would need to be done for a
> sorting algorithm.
> 
>   And that's not all. When adding triangles to the kd-tree, it's trivial
> to detect cyclical occlusion situations, and perform the necessary triangle
> splitting, as a preprocessing step. After this has been done, no more splits
> are ever necessary, and everything can be rendered in a depth order
> regardless of where the camera is (using a simple linear traversal of the
> kd-tree).

Presumably if the triangles are allowed to move around you can't 
precompute the splits?


Post a reply to this message

From: Darren New
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 14:10:41
Message: <4995c5b1$1@news.povray.org>
Invisible wrote:
>  From where I'm sitting, building a parser is quite easy. Still, 
> designing the language it's supposed to parse is another matter - 
> depending on whether you want it to be Turing-complete. ;-)

Or one could use something like Lua or Tcl, which is specifically designed 
for putting extensibility parsers into existing programs, and just implement 
the bits you want and leave Tcl or Lua to do the subroutines, while loops, 
GUI interactions, and so on.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."


Post a reply to this message

From: Darren New
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 14:16:29
Message: <4995c70d$1@news.povray.org>
triple_r wrote:
> Of course you have to compile and link over and over, but how bad is that, really?

Nah. Just embed a decent language and invoke it. Tcl might be OK for this, 
and I've heard good things about Lua. Python is hooked into a number of 
programs I've seen, including Blender.

In Blender, you write your python code to invoke Blender objects and frob 
around the internals how you like, then tell Blender "hey, here's your new 
scene."  Kind of like the way web languages have a "Request" object and a 
"Response" object, and you (say) assign things to response.cookies to set 
cookies at the browser.

REXX is another way to go - sort of like Windows COM only less Microsoft.

Or go with Windows COM or .NET if you're not worried about non-Windows machines.

> Upon reflection, maybe the answer is, "Pretty bad."  I think it's still the
> approach I'd take since I don't actually know how to write a proper parser.

Use one someone already built for you, with the intention that you use it as 
your parser.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."


Post a reply to this message

From: Darren New
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 15:25:56
Message: <4995d754$1@news.povray.org>
triple_r wrote:
>  All without actually having to write or maintain a parser! 

Or you could have a really simple parser, or something that takes XML (or 
JSON or some other complex format for which there's already a standard and 
parsers), and build up your objects from that. Then your scripts are 
programs that output that. Just don't have any loops or variables or whatever.

I mean, it's not really hard to turn something like this into your library 
calls:

1 union
2 pigment 1.0 0.0 0.0
3 sphere 0.0 0.0 0.0 2
4 sphere 1.0 0.0 0.0 2
5 sphere 2.0 0.0 0.0 2
   ...
push 1 3
push 1 4
push 1 5
   ...

Basically, each call to your library is just the name of the routine 
followed by the arguments, and if the line starts with an integer, it's 
declaring something to go in that slot, and you refer to the slots later 
with numbers. Awful to parse by hand, but trivial to generate in a program, 
or even a macro language or scripting language or whatever.  Then you don't 
have to worry about parsing much, and you can write a different library for 
each language like you described that when you're done you say "output this 
to a file and feed it to the renderer."

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."


Post a reply to this message

From: triple r
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 15:35:00
Message: <web.4995d8ab55bca3e6ef2b9ba40@news.povray.org>
Darren New <dne### [at] sanrrcom> wrote:
> Nah. Just embed a decent language and invoke it. Tcl might be OK for this,
> and I've heard good things about Lua. Python is hooked into a number of
> programs I've seen, including Blender.

Good advice.  This is what happens, though, when people with no business
programming try to solve common problems.  They reinvent the wheel, shape it
like a square, weld two tons of steel to it, and argue that, "Hey, it works."

> In Blender, you write your python code to invoke Blender objects and frob
> around the internals how you like, then tell Blender "hey, here's your new
> scene."

So with this method, do you have direct access via python to methods and
functions?  That sure would be useful.  I think I'll need to figure this out
for my soon-to-be-job anyway.

> Use one someone already built for you, with the intention that you use it as
> your parser.

Point taken.  Thanks for straightening me out on the subject.

 - Ricky


Post a reply to this message

From: Darren New
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 15:56:58
Message: <4995de9a$1@news.povray.org>
triple_r wrote:
> Good advice.  This is what happens, though, when people with no business
> programming try to solve common problems.  They reinvent the wheel, shape it
> like a square, weld two tons of steel to it, and argue that, "Hey, it works."

Yup.

> So with this method, do you have direct access via python to methods and
> functions?  That sure would be useful.  I think I'll need to figure this out
> for my soon-to-be-job anyway.

Yup.  Decent blender tutorial that'll give you the idea how it looks when done:

http://jmsoler.free.fr/didacticiel/blender/tutor/python_script00_en.htm
(Follow that to the next page for an actual Python example script.)

Mind, this is the sort of thing Tcl was built for. Indeed, Tcl was up to 
version 3 before you could run a program written entirely in Tcl. (I.e., 
version 3 was the first version of Tcl that came with main() :-) 
Unfortunately, Tcl never really got the reference-semantics thing going, so 
it's difficult to bolt useful OO constructs onto it. But it's pretty easy to 
build your own OO style constructs that Tcl can invoke.

Blender is also open source, so you can peek and see how they integrated the 
Python stuff.

>> Use one someone already built for you, with the intention that you use it as
>> your parser.
> 
> Point taken.  Thanks for straightening me out on the subject.

No problem. Just offering suggestions. Writing your own parser can be fun, 
too, but there's way too much reinvent-the-wheel in this world. Why make 
someone learn a new scripting language when you can say "use this, that you 
already know"? :-)  Indeed, the point of things like COM and .NET is "use 
whatever you already know to run this, including scripts like WSH and 
PowerShell."

There's also something called YAML (Yet Another Markup Language) which is 
semantically identical to JSON but it's readable. You might want to peek at 
that too, if JSON is sufficient.  (JSON is basically maps and arrays of 
strings and numbers, nested. I.e., data structures common to all the 
scripting languages, but surprisingly flexible for a lot of stuff.)

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."


Post a reply to this message

From: Darren New
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 16:03:27
Message: <4995e01f$1@news.povray.org>
Darren New wrote:
> (Follow that to the next page for an actual Python example script.)

Oh, and if you notice, it's simple enough you can probably generate it 
programmatically too. That is, if you wanted to use something other than 
Python, you could probably have your Haskell program output Python script 
that would brute-force its way though the construction of your stuff in a 
very straightforward manner. So you're not losing anything by not having a 
sophisticated scripting language, and it's probably not any harder than the 
"trivial scripting language" example I made up.

The whole blender docs are rooted at blender.org. The manual is broken up 
into pieces that makes it not *too* hard to find stuff, but makes a lot of 
back references, so I'm not sure the "scripting" section would stand on its 
own if you don't know the difference between (say) an Object and an ObData.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."


Post a reply to this message

From: triple r
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 16:10:00
Message: <web.4995e11b55bca3e6ef2b9ba40@news.povray.org>
"triple_r" <nomail@nomail> wrote:
> So with this method, do you have direct access via python to methods and
> functions?  That sure would be useful.  I think I'll need to figure this out
> for my soon-to-be-job anyway.

(Don't worry though.  I know you're thinking, "Wow, I hope they're not paying
him much," but the job has nothing to do with programming.)

 - Ricky


Post a reply to this message

From: Darren New
Subject: Re: kd-trees rule!
Date: 13 Feb 2009 16:12:58
Message: <4995e25a$1@news.povray.org>
triple_r wrote:
> "triple_r" <nomail@nomail> wrote:
>> So with this method, do you have direct access via python to methods and
>> functions?  That sure would be useful.  I think I'll need to figure this out
>> for my soon-to-be-job anyway.
> 
> (Don't worry though.  I know you're thinking, "Wow, I hope they're not paying
> him much," but the job has nothing to do with programming.)

Uh, no, I wasn't thinking that at all. I can't even imagine why you'd be 
likely to have known how Python gets embedded in desktop programs even if 
you *are* a professional programmer. :-)

Me, I've never started a job knowing what I need to know. :-) I'd say maybe 
1 out of 5 jobs I take I wind up using a programming language I've used before.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."


Post a reply to this message

From: Severi Salminen
Subject: Re: kd-trees rule!
Date: 14 Feb 2009 05:38:29
Message: <49969f25$1@news.povray.org>
scott wrote:


> Oh yeh I was going to ask about anti-aliasing, do you get this for free
> too with your algorithm - or do you need to specifically jitter each
> primary ray somehow?

Every ray from the camera goes through one single point. So yes, I have
to rotate each primary ray a bit to cover the area of a single pixel. So
basically I choose a random position within a pixel and trace that
direction. And because you normally do hundreds or thousands of passes
you end up getting perfect antialiasing.


-- 
Severi Salminen
http://www.iki.fi/severi


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.