#3dsr3 troubles
23 messages in this thread
Anyone, I just received 3dsr3 upgrade. I have an animation with 100 frames and
I am trying to render them to disk(Bernoulli) using .jpg format. It does fine
to frame twenty something, but then it either gets out of rendering to
Keyframer mode with no error message or it reboots my computer. Any
suggestions are appreciated. I have a 486-66, 16M RAM, and with this system
had no trouble with 3dsr2.
Thanks,
Mike C.
Mike,
Depending on the compression ratio, JPG's can take up a lot of disk space. Are
you possibly running out of Hard disk space? Check the amount of open disk
space where the phar lap swap files and 3ds temp files are being directed.
-Brian
>> JPG's can take up a lot of disk space. <<
Typically JPG's are a quarter the size of a TGA or less. Do you mean that when
using JPG's that the swap file is larger than when rendering to a TGA or TIF
file?
-JE
<<Typically JPG's are a quarter the size of a TGA or less. Do you mean that
when using JPG's that the swap file is larger than when rendering to a TGA or
TIF file?>>
The size of the JPG image really depends on the amount of compression you
decide for the image to have. I have seen JPG images set for no or little
compression that are only slightly smaller than a corresponding TGA file.
When you are rendering the image, the size of the swap file would be about the
same no matter which format you were rendering to. The only time the swap file
might be different is when 3DS is storing and writing TEMP files in the format
you chose, prior to writing the actual file.
-Brian
Brian,
>> I have seen JPG images set for no or little compression that are only
slightly smaller than a corresponding TGA file. <<
That's very interesting. My experience so far has been as I said a quarter the
size with the minimum compression. Something for me to check into further.
I was trying to clarify what you were saying and your answer to my first
question answered it. My experience is that as you said its the size of the
scene one is rendering not the final format that determines swap file size. Its
been a long time since I swapped a file out. But that's what I remembered.
Thanks, knowing that JPG's can be significantly larger than has been my
experience is good to know.
-JE
Hey John,
Do you know of any command-line utility (such as VGASHOW) that will display
jpgs? Preferably script-able, so I can give a client 1 3.5" disk to preview
instead of 3?! My experience with JPGs has been that they are at least a
quarter of the size of TGA, and usually much smaller. FWIW
–John
PS — Thanks again for the info on the gamma situation — very helpful
John,
You're very welcome on the help with gamma.
With regard to .JPG's I don't know of a utility to display them. I use a
program called Leadview which provides a .CMP file which has better compression
and less loss. They provide a viewer with it. Its a complete image management
system and includes a basic paint package. It will also play AVI files amoung
other things.
They can be reached on Compuserve at 71333,2237 GO LEADTECH or
by phone at 704-549-5532
-JE
John,
I think I'm trading brain cells for pixels, good thing I've got a few. <g> The
LEAD 3.0 supports JPG but the file type is called JFIF. It supports a whole
slew of file formats. Its got more features than I can begin to describe. Well
worth the $99 in my opinion. Good tech support BTW.
-JE
I'll look into it– thanks again!
–John
Joseph,
image alchemy (imgalc.zip – use the graphics filefinder to locate it) is a cool
shareware conversion and display utility that will work on images up to 640×480
(you can register to get support for higher rez's). I have the full-blown
version and use it every day. I guess it's capable of a simple slideshow – no
frills.
I'll look for it — thanks for jumping in!!
–John
PMJI John, and this is a little off the subject focus – but I recently had an
experience where I substituted all JPEG's for the original TGA texture maps in
a scene. Even though the JPEG's were highly compressed and about 1/20 the size
of the TGA's, they actually required slightly *_MORE_* memory in 3DS to render.
Interesting, thought I'd mention it.
BILL
Bill,
>> they actually required slightly *_MORE_* memory in 3DS. <<
Yes that's interesting, by more do you mean more than the original TGA's
required? In other words even though the image was compressed to 1/20th the
size it took more memory than the original image? That's probably what you said
but I wanted to be clear on it.
Thanks,
-JE
Yes, mapped with the MUCH smaller JPEG's, a rendering required MORE memory.
BILL
I'm pretty sure that the reason why the JPEG's required slightly more RAM than
the Targa's is because JPEG's require a little bit of buffer space for
decompression, wheras Targa's don't.
– G
Thanks for clearing that up, as I have been curious about it.
BILL
Garys answer makes a lot of sense. I've noticed it takes much longer
to open a jpg file than an equal resolution .tga, and it's not disk
access that's making the difference.
Yep. I imagine the longer load times for JPEG files is due to the more
complex decompression that must take place. What did surprise me when
using JPEG TMaps was the quality of the rendering was generally much
better than expected. While there was no benefit in using them from a
memory conservation standpoint (a loss actually), using them did
decrease render times substantially. However, I haven't laid any
animation to tape which used them, but I could imagine there could be
problems. If not, and you can get away with it in certain situations,
it is nice to know you can expedite long render times with no great
perceivable degradation. I'll have to try this sometime <g>.
BILL
Wow, I'm going to try using jpegs for some texture maps, in the
future. I guess it's best to use the highly compressed ones for
distant maps, and tga's or nearly un-compressed jpegs for close ups.
I should've gotten my Matrox MAX already, but I'm sure it'll be here
today or tommorrow, unless UPS (I really hate UPS, BTW) screwed
things up. I'll let you know how it works. They're getting 4.2 to
4.5 megs per second throughput with the Seagate Barracude 2.1gig SCSI
drive, which is the one I bought for it. I think compression levels
should be acceptable for many animations.
>> However, I haven't laid any animation to tape which used them, but I
>> could imagine there could be problems.
We use the Hi-8 format, which tends to be a bit "noisy". JPEG artifacts don't
show up enough for this media to show a noticible difference.
>> If not, and you can get away with it in certain situations, it is nice
>> to know you can expedite long render times with no great perceivable
>> degradation
I don't think using JPEG will expedite rendering times much, but it does save
valuable hard drive space when rendering lots of frames.
Thanks for responding!! The time it went back to Keyframer, I went to DOS from
3d Studio and there was 7M left on my hard disk. That is where it swaps. The
Bernoulli 150M had plenty of space for the .jpg files. Any other suggestions?
Thanks,
Mike C.
>> and there was 7M left on my hard disk. That is where it swaps.
7MB really is tight when it comes to swapping. Press "?" in 3ds to see how
much it is attempting to swap out. If you want to do the math, there is a good
section in the manuals about memory usage. It is VERY possible that a
relatively simple rendering could swap out 10MB or more (depending on how much
RAM you have, of course).
I rendered a fairly complex architectural scene on a system with 32 MB RAM, and
still swapped out close to 16 MB. If you find that the status box shows
swapping on a regular basis, you should think about adding more RAM. In the
mean time, make some more space on your hard drive, just in case…
Michale,
David is absolutely right. You need more Swap file space. 7MB is VERY small.
-Brian