POV-Ray : Newsgroups : povray.binaries.images : city buildings-- WIP 9_29_2020 Server Time
28 Mar 2024 12:49:23 EDT (-0400)
  city buildings-- WIP 9_29_2020 (Message 11 to 20 of 49)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Kenneth
Subject: Re: city buildings-- WIP 9_29_2020
Date: 30 Sep 2020 16:20:03
Message: <web.5f74e7d832341a55d98418910@news.povray.org>
"BayashiPascal" <Pas### [at] BayashiInJapannet> wrote:
> You may find some useful resource for collision detection here:
>
>
https://gamedevelopment.tutsplus.com/tutorials/collision-detection-using-the-separating-axis-theorem--gamedev-169

Wow! That's quite complex for my poor brain-- but I will *try* to follow along.
Unfortunately, it looks like some of the visual 'demos' are missing(?)
>
> In your case, the objects are axis-aligned as far as I can see...

Yes, basically a '2-dimensional' field of greeble objects, all at simple
90-degree angles.

> ...so AABB collision detection may even be sufficient. Have a look here too:
>
> https://manbeardgames.com/tutorials/aabb-2d-collision-checks/

Thanks; I'll check that out as well.


Post a reply to this message

From: Bill Pragnell
Subject: Re: city buildings-- WIP 9_29_2020
Date: 30 Sep 2020 16:25:06
Message: <web.5f74e8cf32341a551b6c6b3a0@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:
> At the rate I'm going, my *own* city may forever remain unfinished, ha. Ideas
> beget more ideas, etc. etc. But great fun nevertheless-- and a useful learning
> process, as always.

It's all about the journey, not the destination.

*achieves nirvana*


Post a reply to this message

From: Kenneth
Subject: Re: city buildings-- WIP 9_29_2020
Date: 30 Sep 2020 16:50:05
Message: <web.5f74ee3232341a55d98418910@news.povray.org>
"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:

> > I still don't know the algorithm or technique for placing randomly-located
> > objects that don't overlap, each object having its own space...
>
> You can store objects in an array, and check each new one against existing
> positions and bounds, for example in dodgy pseudocode:
[snip]
>
> Alternatively, you can subdivide your region of interest, then pick a single
> random location in each sub-region. This has the advantage of not requiring
> extensive looping and testing, although subdivision might be non-trivial. For
> rectangles it's not too bad.
>
> If your objects are all roughly the same sort of size, you can lay a grid
> down, perturb the grid positions by some distance smaller than the grid
> spacing, then place objects at the perturbed grid positions. Using only
> a subset of the grid positions makes it look more random.
>
 Thanks a bunch! You've given me some good ideas to pursue. Btw, while trying to
come up with workable schemes 'on my own', I'm happy to say that the
grid-subdivision idea(s) did occur to me at various times, in rather fuzzy
ways-- but I didn't follow up on them. :-( It's nice to know that I wasn't too
far off in my thinking.

And it looks like POV-ray's  min_extent(...) and   max_extent(...) tools will be
useful here, especially since my greebles are of various sizes and shapes.


Post a reply to this message

From: Bill Pragnell
Subject: Re: city buildings-- WIP 9_29_2020
Date: 30 Sep 2020 18:15:01
Message: <web.5f7502f432341a551b6c6b3a0@news.povray.org>
Happy tinkering!

> And it looks like POV-ray's  min_extent(...) and   max_extent(...) tools will be
> useful here, especially since my greebles are of various sizes and shapes.

Don't forget that min_ and max_extent() might not return useful bounds for CSG
objects. It could be a good idea to manually bound your greebles if this is an
issue.


Post a reply to this message

From: Bald Eagle
Subject: Re: city buildings-- WIP 9_29_2020
Date: 30 Sep 2020 20:55:00
Message: <web.5f75280d32341a551f9dae300@news.povray.org>
"Bill Pragnell" <bil### [at] hotmailcom> wrote:

> Don't forget that min_ and max_extent() might not return useful bounds for CSG
> objects. It could be a good idea to manually bound your greebles if this is an
> issue.

Right - but assuming you get a good bounding of the objects (check out jr's
work, and my incomplete attempt(s) )
then perhaps you can use the size of the bounding box of the intersection
between two objects - and let POV-Ray do the heavy lifting.

if there's no intersection, then how big is the bounding box of the intersection
{} ?
0 or NAN, or...


Post a reply to this message

From: Thomas de Groot
Subject: Re: city buildings-- WIP 9_29_2020
Date: 1 Oct 2020 02:56:20
Message: <5f757d94@news.povray.org>
Op 30/09/2020 om 22:17 schreef Kenneth:
> "BayashiPascal" <Pas### [at] BayashiInJapannet> wrote:
>> You may find some useful resource for collision detection here:
>>
>>
https://gamedevelopment.tutsplus.com/tutorials/collision-detection-using-the-separating-axis-theorem--gamedev-169
> 
> Wow! That's quite complex for my poor brain-- but I will *try* to follow along.
> Unfortunately, it looks like some of the visual 'demos' are missing(?)
>>
>> In your case, the objects are axis-aligned as far as I can see...
> 
> Yes, basically a '2-dimensional' field of greeble objects, all at simple
> 90-degree angles.
> 
>> ...so AABB collision detection may even be sufficient. Have a look here too:
>>
>> https://manbeardgames.com/tutorials/aabb-2d-collision-checks/
> 
> Thanks; I'll check that out as well.
> 
> 
> 

I think there is a fairly simple way, close to what Bill suggested, by 
using (1) random placement on the roof and (2) if more objects are to be 
placed to test collisions using the inside(O,V) function. You may need 
to provide a bit more room around the existing object O and the new 
object by using test objects just a little larger than those you are 
going to place.

-- 
Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: city buildings-- WIP 9_29_2020
Date: 1 Oct 2020 03:07:33
Message: <5f758035$1@news.povray.org>
Op 30/09/2020 om 21:40 schreef Kenneth:
> "BayashiPascal" <Pas### [at] BayashiInJapannet> wrote:
> 
>> The buildings seems tightly packed. Simply "forgetting" to place some of them
>> would help breaking the monotony too, as there would be spaces for
>> parking lot, park, etc... in a real city.
> 
> That's a great idea, thanks! It did not even occur to me to leave some 'space'
> for other things, and you are correct-- even in New York City, with its
> EXPENSIVE real-estate values, there are humble parking lots here and there. (At
> one time long ago, I lived and worked in NYC for about a year-- well, I lived
> way off in the less-expensive suburbs, ha.) And small parks would be good too,
> to add some much-needed color and 'humanity' to the city. (At one point, I
> thought of putting small 'gardens' on the ROOFS of some of the buildings; I
> might do that as well.)
> 
> Good ideas!
> 
> 

Look at the trends in some cities to have indeed roof gardens, balcony 
gardens (if you have a balcony) and even whole vegetated curtain walls. 
Architecture nowadays is going green! ;-)

See e.g.: https://www.dezeen.com/features/green/

-- 
Thomas


Post a reply to this message

From: Kenneth
Subject: Re: city buildings-- WIP 9_29_2020
Date: 1 Oct 2020 17:00:06
Message: <web.5f7642e832341a55d98418910@news.povray.org>
Thomas de Groot <tho### [at] degrootorg> wrote:

>
> I think there is a fairly simple way [for collision detection], close to what
> Bill suggested, by
> using (1) random placement on the roof and (2) if more objects are to be
> placed to test collisions using the inside(O,V) function...

The inside(...) function-- that tool sounds really useful for this. I've
actually never used it before(!) Thanks, Thomas. Now I need to do some hard
thinking (ouch).

Btw, another major change/addition to my scene will be to divide the city into
'blocks', with streets going at right angles to each other. It will be a
challenge to implement, because my building-placement code as-is was written in
a way that will not easily allow it.

One problem at a time, ha.


Post a reply to this message

From: jr
Subject: Re: city buildings-- WIP 9_29_2020
Date: 1 Oct 2020 17:25:09
Message: <web.5f76481832341a554d00143e0@news.povray.org>
hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > I think there is a fairly simple way [for collision detection], close to what
> > Bill suggested, by
> > using (1) random placement on the roof and (2) if more objects are to be
> > placed to test collisions using the inside(O,V) function...
>
> The inside(...) function-- that tool sounds really useful for this. I've
> actually never used it before(!) Thanks, Thomas. Now I need to do some hard
> thinking (ouch).

I wrote a macro based on 'inside()' for the purpose (ie getting the smallest
"axis-aligned" bounding box), maybe it'll be of use.

<http://news.povray.org/web.5dc0bff634d8ef06feeb22ff0%40news.povray.org>

> ...


regards, jr.


Post a reply to this message

From: Kenneth
Subject: Re: city buildings-- WIP 9_29_2020
Date: 1 Oct 2020 17:45:05
Message: <web.5f764cc232341a55d98418910@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

>
> The scene so far parses 'reasonably' quickly: For 650 buildings, with AA but no
> radiosity yet--  78 seconds total render time on my old Windows 7 machine (at
> 1600 X 900). The 'peak memory used' is about 1.1MB.
>

Duh. That should be 1.1 GB of memory, not MB. Sorry.

1000 buildings uses about 1.4GB

One trick that I learned long ago was to pre-#declare image_map pigments, when
they are going to be used repeatedly in a scene. That saves a whopping amount of
memory usage later.

Like,
#declare MY_PIGMENT = pigment{image_map{png "my_image.png" interpolate 2}}
#for(i,1,1000)
box{0,1 pigment{MY_PIGMENT} translate ...}
#end

instead of...
#for(i,1,1000)
box{0,1 pigment{image_map{png "my_image.png" interpolate 2}}
translate ...}
#end


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.