masterofcomputers said:
See, I'm already thinking of 2-D image editing. When I make backgrounds, i make them at some un-godly resolution due to having 4 22" monitors it a 2x2 array. Im used to looking at gimp and seeing it say 6-8GB image. My new image size is apx 500 MB so i end up with insane images and files. Thank god 3-D modeling isnt proportional in [Complexity of doing:RAM usage] to 2-D imaging of I would be using all 16GB of RAM.
I have already relized how useful the size of my display is in 3-D modeling. I have a side, front,top, and camera view all open at once (and the online tutorial YAY!).
A second monitor is/can be really helpful too - so you have your 4 views taking up a full monitor with as many tools for manipulating the model/s as possible all displayed on the other monitor. I find those swing-out monitor holding arms to be really convenient for a second monitor that is pretty much only used for graphic work.
As for complexity - 2D images, as used for textures on 3D models for example, certainly can chew up RAM like anything. 3D models themselves however don't eat up RAM at the same kind of rate, even while you're making them, partly because of the completely different nature - it's a bunch of co-ordinates and ways to conenct them. think of it this way - vector drawings vs bitmaps. Vector drawings typically take much less disc/memory space than a bitmap displaying the same image when you have a couple of simple primary colour primitives on a plain background. Let's say a red square and a blue trianlge on an A4 sized image - the vector file can provide sharper, more accurate higher resolution results than the bitmap can, at a lower filesize. As the complexity of the image ramps up, however, the size of the vector file increases while the (uncompressed, consistent resolution) bitmap doesn't*
As the complexity of the image gets closer and closer to that of a photograph, a vector file gets larger and larger until it could actually take more memory/file space than a bitmap would. If, for example, each pixel/dot in each row of pixels is different and unpredictable, the best a vector could do would be to specify a point and colour for each dot - but it would be inefficient for this and take more space than a bitmap which is designed specificlaly for this purpose.
OK - now 3D files are just vector files with that extra component - the 3rd dimension. If a line is specified, instead of holding some data like "Line from X,Y to X1,Y1" you have "Line from X,Y,Z to X1,Y1,Z1". So again, the size of 3D data in memory TENDS to be far less than for bitmaps unless/until you get into some crazy levels of complexity - and I really think that, long before reaching that stage, you'd split the project up into seperate file s(like instead of a model of a city, you'd be doing blocks or even individual buildings to merge put together later on).
Also, don't forget that as in the world of "ordinmary" 2D, compositing is your friend in 3D. When you start using crazy amounts of memory, you split things into seperate jobs that can be spliced together one way or another later, to make rendering times tolerable.
amf66 said:
Cool. I like the second one the best.
Me too - I like the clarity of a sharper image.
So - can I take it that the current mould situation means that unforseeable delays my end, some of which mean I may have better versions of my 2 offerings "soon" but all of which have delayed the other image sI wanted to work on, have given me extra days to get stuff done in? ED? Bueller?
*I am conveniently ignoring file format compression like .jpg compression as a whole other thing, just talking about the raw in-memory vector data and bitmap data in filesize terms here.
