I'm continuing to work on my 'city buildings' scene from a couple of months ago.
I want to turn all the different buildings into height_fields-- not the usual
'from the ground up' HF's, but as the building faces, to add some dimensionality
to them. They probably aren't going to be seen in close-up, but I think they
will look more realistic than just flat-surface box shapes, if only for the
extra shadows they provide.

These are some that I've already made-- they are tiled HFs that I can chop up or
assemble into bigger buildings.  These renders are just basic tests to make sure
that my code is aligning the faces correctly, and to check that the features and
reflections are where they are supposed to be. The thin red line vertical line
at the corners shows that the faces align.  I haven't yet 'scaled' my HF code to
make sure that all the floor-levels of each building are the same height, or
made any '1st floor' artistic modifications (for lobbies, possible store-fronts,
etc... which I haven't figured out yet!)

The shape of the image_maps shows the actual 'tiles' I made, with their various
window repetitions. But my code can chop them up into individual window 'units'
if I want. Some image_maps have more windows, some less.

It's all very tedious Photoshop work, with back-and-forth testing.
The interesting thing about the HFs is, I chose 50% gray as the 'flat face' of
the building, rather then black. This way, I can make indents AND protrusions.
The air conditioning units are one such protrusion; and the last image has been
the most detailed yet.

I haven't yet integrated this HF idea into my main scene code;  some re-working
will be needed there.

The actual building appearance is from internet images I downloaded, then made
into tiles for repetition (same as in my original scene.) Some of those
originals were quite small in pixel-size and had to be blown up to work with (to
create a higher-rez HF).

Post a reply to this message

Attachments:
Download 'buildings_as_hfs_wip_1.jpg' (686 KB)

Preview of image 'buildings_as_hfs_wip_1.jpg'

Wow, those look very nice!


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
> Wow, those look very nice!
>

Thanks. Working on these things is like a Zen experience :-P  HOURS pass by and
I don't even notice.

But I just DID notice, in my first building image, that I forgot to add the
under-window 'ledge' to my HF image_map, so it can stick out a little. Back to
work...!

Post a reply to this message

On 26/02/2018 22:09, Mike Horvath wrote:
> Wow, those look very nice!
> 
> 

Very nice indeed.


-- 

Regards
     Stephen

Post a reply to this message

Smart work! Well done. Maybe tedious work but so rewarding in the end. 
Keep it up!

[I noticed your window ledge too ;-) ]

-- 
Thomas

Post a reply to this message

Forgot to mention that I 'flipped' the height_fields from their usual 3-D
configuration, if that wasn't obvious. White normally represents the most
protruding y-height of a horizontal HF; I just scaled them <1,-1,1> before
rotating them vertically. It was easier for me to make the HF art in the usual
way, rather than deal with 'reverse' gray values there. (Of course, I could have
'inverted' the grays in Photoshop instead, when the work was finished-- but I
may go back to them to add more detail, or to fix mistakes.)

Post a reply to this message

These look really nice, good strategy. However, does this not get memory-heavy
when you have a large number of buildings?

Your posts on this topic have inspired me to go back to a city builder I started
on a couple of years ago - I started with SDL macros but it got too slow and
difficult to maintain, so I'm spending most of my time in C++ at the moment,
making .pov and .inc files from a command line tool. Each of my buildings is a
self-contained mesh2.

Most of my effort so far has been in reading svg files for street maps, and
splitting blocks up to make arbitrary polyonal buildings. Currently I'm spending
a lot of time trying to get random variation in buildings while still retaining
a recognisable style. I'm getting there. I shall post some results at some point
:)

Bill

Post a reply to this message

On 27/02/2018 16:08, Bill Pragnell wrote:
> These look really nice, good strategy. However, does this not get memory-heavy
> when you have a large number of buildings?
> 
> Your posts on this topic have inspired me to go back to a city builder I started
> on a couple of years ago - I started with SDL macros but it got too slow and
> difficult to maintain, so I'm spending most of my time in C++ at the moment,
> making .pov and .inc files from a command line tool. Each of my buildings is a
> self-contained mesh2.
> 
> Most of my effort so far has been in reading svg files for street maps, and
> splitting blocks up to make arbitrary polyonal buildings. Currently I'm spending
> a lot of time trying to get random variation in buildings while still retaining
> a recognisable style. I'm getting there. I shall post some results at some point
> :)
> 

Good to hear.


-- 

Regards
     Stephen

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> These look really nice, good strategy. However, does this not get memory-heavy
> when you have a large number of buildings?
>

Actually, I don't yet know. My original scene-- without the height_fields-- does
suffer from a constantly climbing memory increase, the more buildings I add. I'm
still trying to determine why that is. But my idea here is to pre-#declare the
HFs (at their tile sizes, or as multiples of that)-- to consume memory only
once--then instantiate them into the scene for many building repetitions via
#while loop (and maybe using simple clipped-by planes to then slice-and-dice
some of the windows off to get *whatever* random building-face-sizes I want.)
Although, I haven't yet tried this scheme 'at scale'.

BTW, I eventually want to have as many as 50 different window styles-- thus 50
trios of images to work with.

The idea common to both my scenes is to pre-#declare all the
pigment{image_maps...} too,  before using them in various places in the
#while-loop code-- which does (or should!) save memory as well.

But there is a certain block of code *within* the #while-loop-- an image_pattern
block, common to both scenes-- that may be the problem when finally applying the
window *reflections* (via the hold-out mattes) to the buildings.
Here's a simplified demonstration, using only one style of HF tile:

--- *before* the #while-loop repetitions, to save memory---
#declare PIG_1A = pigment{image_map{...}} // the photo tile of the building face
#declare PIG_1B = pigment{image_map{...}} // the HF-artwork tile
#declare PIG_1C = pigment{image_map{...}} // the hi-contrast hold-out matte
// tile for the window reflections (which actually can't be used-- see below)
#declare HF_1 = height_field{PIG_1B... scale <...>};  // the original HF

-- *within* the #while loop, to make lots of these particular buildings---
#declare FINAL_BUILDING_FACE =
union{... another while loop to make random height-and-width repetitions
// of the original HF tile)...}
........
object{FINAL_BUILDING_FACE
texture{
    image_pattern{
    jpeg "building windows 1 holdout.jpg" //  the *actual* high-contrast
    // hold-out  matte for the window reflections, not PIG_1C. And no 'once'
    // keyword, BTW.
                 }
     scale <432,724,1>/724 // pixel dimensions of hold-out matte (actually
     // of all 3 images)
     texture_map{ // two identical pigments, but one having REFLECTION.
               [0.45 pigment{PIG_1A} finish{...}]
               [0.55 pigment{PIG_1A}finish{...reflection {REFLECT_AMT}}
                }
       }
     }

As far as I've been able to work out, there is no way to substitute PIG_1C or
something else for...
                   jpeg "building windows 26 HO.jpg"

......in order to save on *memory*.

By itself, the latter isn't an 'Rvalue' that can be pre-#declared. (Neither is
the small image_pattern block itself.) Which means that the hold-out image is
constantly reloaded into memory, maybe hundreds of times. And this is for only
ONE building style.

I've come up with only two tricks that actually work, if only code-wise: a
#macro substitution of "building windows 26 HO.jpg", but which basically just
inserts a text string, with no instantiation of the actual image. And a #macro
for
        jpeg "building windows 26 HO.jpg"
but I don't really know if that 'instantiates' the image (i.e., 'caching' of the
macro contents.) I don't think so.

This could be a big part of why the memory footprint of the scene increases, and
I don't yet know how to work around it-- that is, without a 'brute-force' method
of pre-#declaring 50 such constructs as individual texture blocks!

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
[snip]
> This could be a big part of why the memory footprint of the scene increases, and
> I don't yet know how to work around it-- that is, without a 'brute-force' method
> of pre-#declaring 50 such constructs as individual texture blocks!

How about:

Declare a texture block array. Put the filename strings into another array using
an initialiser list, then fill the texture block array by iterating over the
filename array and using Parse_String() (in Strings.inc) to substitute the
filenames in the image pattern statement. Parse_String() is nasty because it
writes an include file then includes it on the spot, but as long as you're not
doing it thousands of times it should be fine.

Unless I've misunderstood a) your description or b) Parse_String() - it's late
here so my brain is shutting down! I'll revisit tomorrow :)

Bill

Post a reply to this message