www.quadsoftware.com
FAQ  FAQ   Search  Search   Memberlist  Memberlist   Usergroups  Usergroups
Register  ::  Log in Log in to check your private messages


Post new topic  Reply to topic
 Beginner question about heightmap import « View previous topic :: View next topic » 
Author Message
davidbrinnen
PostPosted: Sat Mar 26, 2011 11:33 am    Post subject: Beginner question about heightmap import Reply with quote



Joined: 25 Mar 2011
Posts: 17

I've got procedurally generated heightmaps in Bryce 7.1 that I want to get into Grome.

Bryce will export

16bit greyscale png and tif.

I can also copy the heightmap into the clipboard from Bryce's terrain editor and then paste it into a paint application.

I've tried saving this then as raw format from the paint program.

Grome does not appear to accept either png or tif on import as far as I know...

Nor can I find anywhere I can paste in the heightmap directly from the clipboard which would be the easiest solution.

The raw files load but appear corrupted. The reported resolutions do not match and the results are stripy. Can anyone offer me any hints as to what I may be doing wrong? The paint package I'm using is Paint Shop Pro version 8.
Back to top
View user's profile Send private message
davidbrinnen
PostPosted: Sat Mar 26, 2011 5:34 pm    Post subject: - Reply with quote



Joined: 25 Mar 2011
Posts: 17

Using Hightmap > HmapImport > Source

If the image selected is the Bryce native 16 bit export png.

The image is not loaded into the thumbnail and applied.

If the exported image png is compressed down to 8 bit greyscale in PSP8.

It will load in and can be applied as a brush. But at that point, so much height information has been lost that the result is very "stepped".

I would load examples up to explain what I mean but I do not know how to add images to the forum posts.
[/img]
Back to top
View user's profile Send private message
davidbrinnen
PostPosted: Sat Mar 26, 2011 7:54 pm    Post subject: - Reply with quote



Joined: 25 Mar 2011
Posts: 17

Another quick question.

How come on export as png.

The input information says: Terrain size: 1024, 1024
The output says: Heightmap output size: 1025, 1025

I have tried a few combinations of cell size and zone numbers and I seem to be able to obtain exact conversions. Where am I slipping up?
Back to top
View user's profile Send private message
ALicu
PostPosted: Sun Mar 27, 2011 9:35 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hello,

Grome can import 16 bit one channel raw, BT, DTED, and GeoTif formats as heightmaps.

Quote:
Using Hightmap > HmapImport > Source


This is the quick import tool which for now it is meant only for small terrains and can accept only a greyscale bitmap (1 channel, 8 bit) so it cannot support (just yet) higher precision data (16bit).

For import of high precision height data use one of the above mentioned importers.

Quote:
The input information says: Terrain size: 1024, 1024
The output says: Heightmap output size: 1025, 1025


The size of the terrain zone is given in tiles number. In Grome terminology a tile is a small square made of 4 vertices in the heightmap. So basically the tile size is the distance between two heightmap vertices. On a terrain zone edge if you have 1024 tiles you have 1024 + 1 vertices.

Grome can use any number for the terrain zone tiles (vertices), not necessarily power of two (128, 256, 512 etc) but I recommend creating multiple zones (and not to exceed 2048 per zone, all depending actually on you available memory, video and RAM).

I recommend trying to use raw or DTED for exchanging data with other programs. For raw there are several image editors that can produce the files (16 bit, one channel, no header, IBM pc order of bytes). For DTED you can use GlobalMapper. Dted is especially good when you have the data coming from real-world locations (georeferenced data).

A 16 bit png importer I think will also be handy in your situation and we will check if we can implement a simple importer quickly.

Regards,
Adrian L.
Back to top
View user's profile Send private message
davidbrinnen
PostPosted: Sun Mar 27, 2011 11:21 am    Post subject: - Reply with quote



Joined: 25 Mar 2011
Posts: 17

Thank you for that information, ALicu.

I understand now the discrepancy. I am too stuck in the mindset of thinking of heightmaps in terms of pixel based images and not as tiles. My thinking will have to be adjusted.

Your video tutorials I'm slowly making my way through. They are clear, no problem, and a voice over commentary would make them clearer I think.

Now I understand that an exported heightmap can be comprised of several zones I am not trying to generate such huge single zones and things are running a bit smoother.

A 16 bit png importer would indeed be very welcome. Since it would interface nicely with the Bryce export options.

The key reason for wanting to originate the heightmap from Bryce rather than starting the process in Grome, in case you are wondering and thinking it is slightly perverse is this.

The heightmap in Bryce can be generated from a procedural texture.

And...

This same procedural texture can be used in the material process and aligned with the terrain (the very terrain it has been responsible for generating).

The practical upshot of this is to use the highmap generation procedural (after filtering) to align wave crests along the shoreline. Because of the interlinking of the two textures, this can be done with 100% precision with no need for tedious painting around massive terrains.

Because all this is generated on the fly as the scene is rendered, using procedural texture components has very little memory overhead and there is no evidence of any pixels no matter how close the camera is moved to the scene.

So long as I retain the edge of the terrain where it intersects with my water surface I can edit the rest of it in Grome and still retain the advantages of this texturing method.
Back to top
View user's profile Send private message
ALicu
PostPosted: Sun Mar 27, 2011 5:15 pm    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi,

Yes, I think the different approaches between the two programs are due to the fact that Bryce is more offscreen render oriented (doing non real time rendering images) while Grome needs to follow the guidelines of a real-time rendering application (more oriented towards 3D).

So Grome needs to keep its textures in memory, organized per layers (and eventually it needs to use multiple rendering passes to present them each frame). Bryce on the other hand can generate them only once, when obtaining an offline image from a single angle.

That being said, you can still use the heightmap together with texturing in Grome. Basically the generation of textures (layer colors and their masks) is mostly based on heightmap features (generation of coverage based on altitude, orientation, slope etc). You also have the selection layers which you can paint or generate and use to affect both heightmap and texturing (and also other types of layers: water, vegetation etc).

I am not very familiar with Bryce, but after you get more familiar with the program you may figure out that Grome approach offers you the same editing results but with immediate visual feedback. Anyway, we are very opened to any suggestion from users experienced with other programs. Features which were specific only to offline rendering are now becoming available to be represented in real time. So we are discovering each day new ways to add detail to our real-time terrain (e.g. lately we were thinking of procedural textures generated on the fly on video cards shaders).

Regards,
Adrian L.
Back to top
View user's profile Send private message
davidbrinnen
PostPosted: Sun Mar 27, 2011 6:55 pm    Post subject: - Reply with quote



Joined: 25 Mar 2011
Posts: 17

Hi Adrian,

I will certainly be experimenting with Grome's texturing approach. Indeed it is possible to mix and match procedural and picture sources for Bryce materials. So as to get the best of both worlds - so to speak.

One options, I do not know if it has already been considered, or indeed has already been implemented?

Is to use procedural methods to place and blend picture based textures. This is a little more processor intensive than just putting the textures down in a grid, but it does have the advantage of breaking up the sometimes very obvious repetition of picture textures over large uniform surfaces.

Another option would be to implement procedural textures and have them "baked" into picture textures for final export. Just as is possible with shadowing when producing an occlusion map. The nice thing about procedural textures, as opposed to image based textures, from my point of view is that they offer (in Bryce at lest) far superior generation of bump mapping response and also, can be used to drive other more sophisticated effects from their alpha like anisotropic shading and so forth.

Cheers,
Back to top
View user's profile Send private message
ALicu
PostPosted: Mon Mar 28, 2011 6:50 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi David,

Quote:
Is to use procedural methods to place and blend picture based textures. This is a little more processor intensive than just putting the textures down in a grid, but it does have the advantage of breaking up the sometimes very obvious repetition of picture textures over large uniform surfaces.


I don't know if this is what you are referring to, but you can indicate filter images for the MaskGen/ColorGen tools. Basically, in these tools you can add multiple distribution layers, each with its own settings. These distribution settings means restrictions of altitude, slope, direction where the Grome layer is visible. Besides this, as stated above, you can indicate an image which further filter the visibility of the layer. This image is tiled and further restrict where the layer is visible thus creating more variation. You can have one or multiple distribution masks assigned when computing a layer mask so you can use many filter images at once for the same layer. Please refer to the help for details (see Grome.chm at Terrain Texturing -> Color Generator and Mask Generator).

Quote:
Another option would be to implement procedural textures and have them "baked" into picture textures for final export. Just as is possible with shadowing when producing an occlusion map. The nice thing about procedural textures, as opposed to image based textures, from my point of view is that they offer (in Bryce at lest) far superior generation of bump mapping response and also, can be used to drive other more sophisticated effects from their alpha like anisotropic shading and so forth.


Yes, the procedural textures offer great advantages. One of them, from my point of view, is per-pixel resolution (high resolution, basically a one-to-one with the final image). Grome, on the other hand, needs to represent the texturing in real-time so it has to represent it by some sort of blending of multiple images, each at fixed resolution. That being said, we are thinking of procedural generation on the fly in pixel shaders and combine it with the current approach.

Regards,
Adrian L.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Based on a template by Dustin Baccetti
Powered by phpBB © 2001, 2005 phpBB Group