LightWave + 200Mb of textures = crash


#1

Does anyone else have problems with rendering when using more than 200Mb of textures on a model in LightWave? I sure do. I don’t even get an error message, LightWave just closes. How am I supposed to get work done if this happens every time I hit render?

I tried changing the priority of LightWave in my Task Manager. I have a fast, stable computer with a lot of RAM. I don’t understand what the problem is.

I tried downsizing all the textures, and that works without a problem. But I have to do tests with the high res textures because of the nature of the work, and yet this is totally preventing me from doing so.

Will it make a difference to try rendering through Screamernet?


#2

Leigh,
A couple of ideas:

  • Are you in 8? Did you try it in 7.5?

  • Did you try changing the image format to something else? I think I’ve seen that posted in the past as a possible solution.


#3

Hi Brap :slight_smile: Thanks for the reply.

  • Nope, not 8. I am using 7.5
  • Yes, I could change the texture format, but that would defeat the purpose. I am using TGA, because that is what I have to use… I know that TGAs have larger file sizes than something like JPGs, but for this particular job I have to use TGAs.

It’s just that LightWave shouldn’t be doing this. I mean, it’s supposed to be suitable for film use, yet why can it not handle 200Mb of textures? I have 2Gb of RAM on this machine, which is more than enough to handle that amount. That’s what I find so puzzling.

It’s so very frustrating :sad:

I think I will try rendering it through Screamernet…


#4

There a great book out on texturing - LIGHTWAVE 3D 8 TEXTURING, might have the answers, take a look at that.


#5

:rolleyes: !!!


#6

I have had problems with scenes that have a lot of textures. I tried to nail down the upper limit but I couldn’t. One day it was as low as 100MB and now it seems to work fine. I think it may have something to do with OS overhead, stupid win 2000 with tons of anti-this and anti-that running. Also I don’t have admin privledges so I can’t change swap file sizes and stuff.

I’ve heard this a few times with LW8, is it always windows? what are you guys running?


#7

You’re right, it shouldn’t be doing that. I recently rendered a scene out with about 250Mb worth, also using TGAs, so it must be something related to your scene.One thing I have had problems with regarding hires textures are some of the image processing & editing functions. Anything going on in there?
Another idea: There was a thread on the Newtek board where the TGAs were somehow corrupt, and bringing them into Photoshop and re-saving them fixed the problem.


#8

Oh, just re-read, you are using 7.5? i was using 8

My solution was to change the texture size and make it smaller, jpg’s don’t change anything because they have to be uncompressed at render time anyway (guess?). This was not fun, it was a really big satalite image for a terrain texture and making it smaller really degraded the final quality, but it had to be done.:shrug:


#9

Hi Leigh,

Don’t know if you’ve tried this already, but turning off OpenGL textures if you don’t need them might work. LW seems to use vast amounts of RAM to cache OGL textures.

Nic


#10

Does LW lock up or crash? I’ve noticed that after a certain point LW starts loading stuff slower than snail crossing a piece of sand paper so maybe it’s just that? :shrug:


#11

Thanks a million for the replies, guys :slight_smile:

skritter - har har.

uncon - I am currrently running under Windows XP Pro. I shut down a lot of the unnecessary background processes running in the OS, and intentionally kept this machine off the web soI wouldn’t have to run firewalls or anything else like that. I have also kept it streamlined by installing very little on it - I only have a couple of applications installed. So it’s a clean, efficient machine :slight_smile:
So yeah I’ve had to change the texture sizes, plus I’ve converted all the non-colour textures to grayscale (which reduces the file sizes considerably). The problem is that this stuff is for film, and I need to check that the textures look okay at film resolution, so it becomes a problem when I am checking using half/quarter resolution textures as they are not an accurate indication at all. So you see my dilemma :argh:

brap - actually, this was just over 250Mb, so maybe that’s the cutoff for LightWave :scream: The TGA files are fine - I created them in Photoshop :slight_smile: Plus as soon as I reduce their size, bam! No more crashing! But as I said above, this interferes somewhat with what it is that I am supposed to be doing.

Freebooter - thanks for the suggestion, I already switched them off though :slight_smile: Heh, that’s one of the first things I always do when problems arise.

I’m having a bad day :cry:


#12

It just crashes. Closes down, sometimes with an error message from Windows, but usually without any error message at all. It’s like it just thinks “bugger this, I’m outta here!”.

By all appearances, it’s as if LightWave is running out of memory. That’s the most logical explanation, and I’m a woman of logic :slight_smile: However, the frustrating thing is that LightWave doesn’t have user-defined memory management… perhaps NewTek should consider implementing this into LightWave 9. All the same, considering the fact that I have 2Gb of RAM and I am rendering this on a dual 3.06Ghz Xeon, I wouldn’t have expected to encounter such an issue :shrug:


#13

Okay. I asked about your problem from a guy who does a lot of graphics stuff for living and he said that the reason LW crashes is that your graphics card can’t keep up with LW which is sending too much data. One solution is to turn wireframe mode on before loading the object/scene and turning the OpenGL texture resolution as low as possible.

Hope this helps :slight_smile:


#14

Para, thanks for going to the effort of asking someone else :slight_smile: The problem isn’t when loading though - I can get the object in fine, with no hassles or speed problems at all. It’s when I try rendering that LightWave crashes :sad:

Hey guys, thanks for all the helpful suggestions, I really appreciate it all. I think I’m just going to have to use smaller versions of the textures and hope that when the studio renders it, it will look alright…


#15

Would lowering the segmented memory settings in Lightwave help? If the scene won’t render in one segment, then maybe it’ll work if split into multiple segments by lowering this setting.


#16

Hi Leigh,

I kinda guessed you’d have tried turning the OGL off, I’d vote for screamernet and/or multipassing the render. SN seems to handle heavier scenes a lot better than LW.

Nic


#17

I’ve had the same problem, even with 4 gigs of ram and two processors. Lightwave has never been very good with high res renders or high res textures, IMHO. I also tried rendering with Screamernet, and it helped in one instance–a scene with a little under 200 megs of textures–but still failed the other times.
Switching image formats is a good idea…


#18

Have you tried breaking up the scene into multiple passes (like the article in the new Keyframe mag)? It may be your only option if you want to stop messing around with the thing and get it out today.


#19

Not many options left. One thing you could try though. Switch to single CPU by setting up just one thread. You can also force this with the task-manager (right click) on Lightwave.exe. Not a solution but might help locating it. Perhaps your’e using a plugin that doesn’t do well in multihreaded env with large images.

I heading towards a model with at least 100MB of images. No I know what’s in store :frowning:


#20

Hey Leigh,

By any chance are you using image sequences for texturing? I had a problem where LW would just disappear and the only way I could get it to work is to scrub the image sequence in the image editor before an F9/F10. It would not work at all through screamernet.

Does it crash screamernet? If it doesn’t I guess you could work with lowres proxies in Layout until rendertime.

Also, do you need TGAs at 24bit colour? You could also try resaving the TGAs to 16bit colour for more memory savings but keeping the resolution, although you might get banding.