Print resolution renders >:(



Why after years of development this f**** piece of sssss … software, isn’t able to render properly high resolution images ?

It doesn’t mind if you render using limited regions (even without borders), apparently this stupid program always tries to allocate enough memory to render the entire frame!

This kind of stupid issues is what makes me look to other applications with envy. I think lightwave it’s TOO much bruteforce oriented. You want GI ? Buy a render farm, you want Hires renders ? Buy lots of memory. People of Newtek: MAKE LW SMARTER, NOW. You are loosing ground faster and faster.

And why the hell doesn’t take advantage of virtual memory?! I set the swap file to 4Gb and didn’t help. :banghead: :banghead:


Actually if you render with Limited Region, it’ll only render that area…unless that’s been changed back recently…I’ve found it’s the only way to do some things. It does try to allocate for the entire image if you have either the render progress window or render display on though.

Not that I don’t agree that it should manage memory better, especially since it makes any Image Process effects near-useless, but Limited Region does and can work.



Render Progress: OFF, Render Display: OFF, Render Resolution: 7000 x 5000, limited region: a little tiny (very very tiny) box. Results: bye bye.

Render Progress: OFF, Render Display: OFF, Render Resolution 3500 x 2500, limited region: OFF. Results: Render OK.

Of course: rendered after a clean boot, all proggies closed, using LW and LWSN, Changing Segment memory limit from very low to very high settings, setting swap file to maximum, memory banks are OK (tested in two different computers with the same result).

My config: Athlon XP 2100+, Windows XP, 1Gb. LW 8.0.1

My Scene: nearly 2,000,000 polys, 70 Mb of images, Object memory: 238,3 Mb, Render memory 91,3 Mb (information supplied by Lightwave)



By the way, I’ve thought of the possibility of the existance of a ‘magic’ proggy which made the OS think that there are lots of physical memory installed in the system, something like the way Windows manages virtual memory, but better. Apparently LW only see physical memory for some issues and ignores virtual memory. A program which works in the way i said before could help incredibly.

I did a quick search on internet without luck. Anyone knows about something similar ?

OMG i’m gettin insane ! :banghead: :cry:


Hmm, very odd, must be some other factors in the scene at work there. The stuff I’ve had to render recently was 7000x8500, but only 500,000 polys and very few image maps. I ended up rendering in two limited regions for some things.

I haven’t updated to 8.0.1 yet, but that works in 8.0 at least. P4 3.2ghz, 2gb ram.

I hope it’s not an Athlon vs. Intel problem with their SSE2 implimentation or something else stupid.

No idea what else it could be, aside from your scene being extremely super complex.


it’s because even with limited region, lighwave still have to be able to store the entire frame buffer in memory.

I think lightwave needs twice the memory it should need : frame buffer + segment (or region) buffer, that why with such high rez, even with a region of 1 pixel the full frame buffer can be to big to be stored in ram

BTW lightwave can’t handle more than 2 Gb on PC so a huge swap file won’t change everything, you will have to rely on slower mac to render the biggest scene (!!)

another bad memory handling is with the file saver, this one also need to store the entire frame buffer to conver the internal buffer to a standard image (psd flx or whatever), so now we have 3X the needed memory : frame buffer + segment + file saver ! (and this is also affecting Fprime, sometime it can compute a image, but it can’t save it, leaving you with its rawhdr files)

I really hope newtek will do something, OSs are slowly migrating to 64 bit, hardware is already 64 bit, but with PC Lightwave can’t even use 4Gb (the theorical 32bit limit)



you have confirmed my fears.

So, i have to trust that a render that takes 15h. or more will have a happy end.

In other words, if the render starts doesn’t mean i’ll obtain the final image.

I have had problems with this time ago, but my scenes were much simpler and took only 2h. for such resolutions. sometimes the saver failed. I noticed that PNG saver took less memory compared to JPG or TIFF (no idea what’s the reason). I have read in other thread that using FLX saver could help because it dumps the file direct from LW buffers without further intervention and doing that it saves lots of memory (i’ve not confirmed it yet).

I think NT can easily solve this problem (partialy) with two aproximations.

  • By adding an option to force LW to render (or using frame buffers) in 24 or 32bits, instead of 128bits. I don’t need those extra bits to paste my image on a billboard.

  • By making lightwave to reserve enough memory only for the limited region. I thought this was made when i discovered the option ‘Limited Region No Borders’ but not. Maybe it saves memory when saving to file.

So, actually we have to:

  • Divide the scene in several slices via Splitrender.
  • Make a clean boot to avoid memory fragmentation.
  • Close unneeded programs and services.
  • Render using LWSN using a BAT file which renders all the slices using the -3 option of LWSN.
  • Previously we set image saving with FLX saver (?)
  • Previously we set limited region to NO BORDERS. Splitrender creates the slices by making one scene file for each part of the render, but can’t set the NO BORDERS option by itself (that option didn’t exist when the plugin was made), so will have to edit each scene with a text editor modifying the line which says ‘LimitedRegion 1’ and changing it to 2.
  • Pray.
  • And finally, if our prayer have succeded we have to solve a puzzle in photoshop because the second part of Splitrender plugin doesn’t work in LW8. But it doesn’t mind because by setting the NO BORDERS option i’m quite sure we had ended with a mess of a render.


I hope it’s not an Athlon vs. Intel problem with their SSE2 implimentation or something else stupid.
I doubt it:
I use a dual Xeon processors with HT (2.66 GHz) with 3 Gigs of Ram. This past week, I had to render out a scene at 7"x5" at Print resolution (300 dpi)… and it took 5 days to render!!! And even then, the Depth of Field that I use was so poor that I had to take it into Photoshop for additional edits (which I normally do anyways, but the banding of the DoF was so bad I had to redo the DoF in PS from scratch…).


have you tried rendering the scene in passes? should save on your render times/complexity and save you the trouble of having a looooong rerender if something doesn’t come out the way you want it.



If “by passes” you mean did I render out the elements of the scene individually (characters, enviroment, etc.), then no I did not; looking back on it, it probably might have helped if I did that instead. However, my point was that even though my system is fairly high up in terms of technical power, it still takes too long for LW to render out an image for print resolution.


that would help, you could also do shadow passes, reflection passes, etc. not saying there’s not necessarily a flaw in the software because it sounds like there is, but at the same time you learn to work within whatever limitations you have.



Well, figured out anohter part of the problem: my segment memory setting was too low (it was set to 150 MB). I cranked it up to 2000MB and now my renders are much faster.


[QUOTE=kangonto]- Previously we set image saving with FLX saver (?)

  • Previously we set limited region to NO BORDERS. Splitrender creates the slices by making one scene file for each part of the render, but can’t set the NO BORDERS option by itself (that option didn’t exist when the plugin was made), so will have to edit each scene with a text editor modifying the line which says ‘LimitedRegion 1’ and changing it to 2.

I back Kangonto.
As I’m not a LW user, I missed this option in LW8. Would you be cool to come to SR - Support (English) and explain me what are the changes about, what you are changing in scene files…

Thanks in advance.


It’s quite simple, The Limited Region NO BORDERS option renders the image cropping the black borders corresponding to unseeing parts.

The interest of using this option is simply because supposedly (not confirmed) it saves memory while saving image to disk comparing with the traditional Limited Region option.

Splitrender doesn’t consider this option so it creates the scenes corresponding to slices of the scene with the ‘Limited Region with borders’ option. It’s easy to change this without opening each slice in layout by editing each scene file with a text editor and changing to ‘limitedregion 2’ where says ‘limitedregion 1’.

Obviously, by doing this, the second part of the plugin is useless because each part of the final image isn’t what’s intitially expected.

I don’t find necessary to post this in your Forum, even more when registration it’s in French. Also, i have to confess that i’m very lazy when registering to forums or Webs or things of the like.



A couple of things. Limited Region Borderless or with borders takes the same amount of RAM - the amount needed for a full width render of the height you have set. If you are rendering an image of 7,000 x 5,000 and you have set a limited region of only 128 x 128, it will still need the memory to render 7,000 x 128.

Second thing. You can limit LightWave to not rendering in full bit depth. Go into Effects > Processing (Ctrl F8) and choose Limit Dynamic Range. You can also limit the amount of memory LightWave takes for images if you switch off mip-mapping in the Display Options settings (well it will prevent LW from prematurely mip-mapping your images).

Lastly, to Artistic Visions. The reason that there was so much banding in your DoF is probably because you rendered in several limited regions? The banding is caused by LightWave not knowing what to do with the DoF when it reaches the edge of one of these regions. There are other image processing functions that really need a single region render to work, like Corona and Bloom, so be careful.



I refered to the possibility that with NO BORDERS, may exist a memory saving only when dumping to a file, at last it sound quite logical for me. It’s not the same (for the file saver) to deal with a full frame (even with black borders) that with a limited region of it. Well, if it sounds logical doesn’t mean that the boys at NT had programmed the thing the way it’s supposed to be less memory agressive.

About the other options you mentioned: Do you refer to ‘OPenGL Mipmap’ ?, well, it’s deactivated by default. By the way, obviously with such memory intensive scenes, i always work in Wireframe or Shaded Solid.

I’ll check the option ‘limit dynamic range’ if it works, it could save huge amounts of RAM!

Thanks, BeeVee. :slight_smile:


Using ‘limit dynamic range’ doesn’t help. :sad:.

Apparently LW still tries to allocate the same amount of memory to store the 128 bit version.

Talking of logical or illogical. :banghead:


This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.