Results 1 to 11 of 11

Thread: Modelling a gigantic Mars. Problems with 32 floating point DEMs

  1. #1
    Registered User
    Join Date
    May 2020
    Location
    Alabama
    Posts
    5

    Modelling a gigantic Mars. Problems with 32 floating point DEMs

    I'm trying to import TIFF 32 bit floating point images to LW, that I exported from GlobalMapper. Lightwave doesn't seem to like this format (images load, but load black), but my images are very large also, over 92k by 46k pixels. I tried splitting the map, but I'm getting the same error. LW doesn't seem to accept floating point images.

    I don't want to use 3rd party software to load these maps in, I just want to use LW's tools.

    The attached image is done using the same map in 8 bit, but as you can see, I get artifacts. I've tried everything, and I'm out of ideas. I'd appreciate any input at this point.

    Click image for larger version. 

Name:	1.png 
Views:	61 
Size:	451.3 KB 
ID:	148021

  2. #2
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    8,096
    92000 * 46000 * 4 (RGBA) * 4 bytes (size of float) = .... 63 GB....

    Really?

    The attached image is done using the same map in 8 bit, but as you can see, I get artifacts.
    If it's RGBA 8 bits per channel it is taking 4x less memory than 63 GB = ~16 GB

    In Image Editor you can see how much of memory each image does take.
    What it is showing?

    I've tried everything, and I'm out of ideas. I'd appreciate any input at this point.
    How much of memory do you have in your computer.. ?

  3. #3
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,950
    Quote Originally Posted by Planeguy View Post
    I'm trying to import TIFF 32 bit floating point images to LW, that I exported from GlobalMapper. Lightwave doesn't seem to like this format (images load, but load black), but my images are very large also, over 92k by 46k pixels. I tried splitting the map, but I'm getting the same error. LW doesn't seem to accept floating point images.

    I don't want to use 3rd party software to load these maps in, I just want to use LW's tools.
    Depending on how much memory is in your machine, that's not too likely to work, for reason Sensei already mentioned (img is ~63GB itself). Hmm, actually, if mipmaps are enabled, memory consumption will actually be more, as you'll also have to spend physical and GPU memory on power-of-two-divided transient LoD textures as well.

    You should be aware that even if it shows as "black" in LW imagemgr/viewport, it may still render with details. Such a large image means OpenGL will take a long time trying to sample itself a viable mipmap from CPU memory to GPU memory in order to display in the viewport, but VPR might actually still be able to display a rendered image (if LW itself actually can load the image into physical (CPU) memory) because unlike viewport, rendering samples CPU memory.

    Also keep in mind that unless you have something large enough that applying a 92k by 46k pixel map yields minimum of one visible pixel for every image pixel, you're just wasting memory. If you're dropping from high orbit (where whole sphere is visible) down to ground level, perhaps justifiable (not really, can still be done much more efficiently), but otherwise you're most likely wasting a huge quantity of memory loading that image.

    What you need is DB&W's InfiniMap plugin. It exists to deal with this precise "giant image texture" scenario. Third-party, but that's because not everything CAN be handled, let alone handled efficiently, in native LW.
    Last edited by jwiede; 06-01-2020 at 07:05 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  4. #4
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    8,096
    Even if somebody has 128 GB memory plugged, but memory is fragmented, but app requires one big chunk, it won't be able to allocate it and will fail..

  5. #5
    Registered User
    Join Date
    Aug 2016
    Location
    a place
    Posts
    2,342
    try loading the tiff into photoshop. chop it up.

    must be a way to export in parts of reduced size from globalmapper

    think the biggest ive loaded in tiff format is about 16gb

  6. #6
    precisely you can only see a quarter of the planet in the render, use that quadrant only, also is this greyscale float image or full colour, if so use a greyscale float for the elevation and a much reduced colour image for the texture

  7. #7
    Super Member JohnMarchant's Avatar
    Join Date
    Mar 2003
    Location
    Murcia, Spain
    Posts
    3,173
    DBW InfiniMap could be an answer to what you need.
    Dell XPS 15
    15.6-inch (3840 x 2160) 4K 282ppi IPS LCD
    Intel i7 7700HQ 2.8GHz
    Windows 10 64Bit
    NVidia GeForce GTX 1050
    1TB SDD
    32Gb Ram

    LightWave 2020

    Very nice Laptop

  8. #8
    Registered User
    Join Date
    May 2020
    Location
    Alabama
    Posts
    5
    Quote Originally Posted by Sensei View Post
    92000 * 46000 * 4 (RGBA) * 4 bytes (size of float) = .... 63 GB....

    Really?



    If it's RGBA 8 bits per channel it is taking 4x less memory than 63 GB = ~16 GB

    In Image Editor you can see how much of memory each image does take.
    What it is showing?



    How much of memory do you have in your computer.. ?
    I've got 16GB, but planning to upgrade to 32. After export from global mapper, the image is about 11GB. I haven't measured the memory usage yet.

  9. #9
    Registered User
    Join Date
    May 2020
    Location
    Alabama
    Posts
    5
    The problem is, it loads up (after a while waiting) and then in image editor it shows as black. When I try to see it on vpr, the elevation is not there.

  10. #10
    Registered User
    Join Date
    May 2020
    Location
    Alabama
    Posts
    5
    Thanks everybody for the help. I tried splitting the image in sections, but like I said, it's not working. It won't load the 32bit image, but it will load 8 and 16bit, but those will show those artifacts on the surface. I have LW 2019. I'm using nodes to create the surface using the new surface tools in LW. I haven't tried using geometry, but that would be overkill.

    I'm aware of infinimap, but since this is a model I want to sell, I can't use it for this project. If it was a personal project, I'd absolutely use it as it's far better.

  11. #11
    Registered User
    Join Date
    May 2020
    Location
    Alabama
    Posts
    5
    Quote Originally Posted by jwiede View Post
    Depending on how much memory is in your machine, that's not too likely to work, for reason Sensei already mentioned (img is ~63GB itself). Hmm, actually, if mipmaps are enabled, memory consumption will actually be more, as you'll also have to spend physical and GPU memory on power-of-two-divided transient LoD textures as well.

    You should be aware that even if it shows as "black" in LW imagemgr/viewport, it may still render with details. Such a large image means OpenGL will take a long time trying to sample itself a viable mipmap from CPU memory to GPU memory in order to display in the viewport, but VPR might actually still be able to display a rendered image (if LW itself actually can load the image into physical (CPU) memory) because unlike viewport, rendering samples CPU memory.

    Also keep in mind that unless you have something large enough that applying a 92k by 46k pixel map yields minimum of one visible pixel for every image pixel, you're just wasting memory. If you're dropping from high orbit (where whole sphere is visible) down to ground level, perhaps justifiable (not really, can still be done much more efficiently), but otherwise you're most likely wasting a huge quantity of memory loading that image.

    What you need is DB&W's InfiniMap plugin. It exists to deal with this precise "giant image texture" scenario. Third-party, but that's because not everything CAN be handled, let alone handled efficiently, in native LW.
    That makes sense. The problem I still have is, if I export the map in tiles, or quadrants, etc, as a 32 bit floating point, the images won't load. Maybe the tiles are still too large for LW to handle. I don't know. I may have to try several much smaller tiles and see if that works. Thanks mate

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •