>>7680
I think you missed the part where I said I only have a laptop and no desire to go buying an entire new computer just to attempt fucking about with a free rendering package?

I'd also question how you were able to get hold of a Xeon of any kind, never mind plus video card and memory, given that the latter have certain minimum prices even for shitty ones, and the former is a SERVER CLASS CPU. Do you work as an IT tech and steal an old server then upgrade it or something?

The video hardware is what's integrated to the CPU, but as it's an i5 it's not that terrible, I can play a lot of reasonably sophisticated games with little trouble, and it renders the viewport OK for almost everything, just occasional items appear to crash. I can't be at all certain it's not buggy code in either the program or the object files, though. Rendering via OpenGL produces images of the same quality in "quick" mode (and usually in a fraction of a second), somewhat fucked up and overlit in "high quality" mode (driver or software issue, then, not detecting the actual hardware capabilities?), and presumably as good as what anyone else would have in the main (software + hardware-assistance) mode, just rather slowly for certain things. When I can get to the rendering stage, that is... so far it's been very hit and miss and never more than one character, one background/simple environment, and maybe one prop. The crash point can come even as I try manipulating the character with various poses, but usually when trying to import other items.

Maybe it's a memory thing, but:
1/ I've got shitloads of swap space, so I'd expect maybe chronic slowdown, but not out-of-memory errors (though possibly that's what the access violations translate to?)
2/ Most of the time, if I have Task Manager running (which I do fairly often thanks to web browser BS), the allocated memory count doesn't max out, or even get too close to that point
3/ They're all 32 bit versions of the software (which implies they should work with 4gb RAM or less), necessary as I have a 32bit OS, often the minimum memory given is less than what I have, and no warnings are given e.g. that you may suffer instability or serious restrictions on usability by using that version, or having limited amounts of memory, or that you need to run a machine and an OS version capable of memory address extension in 32-bit mode, with more than 4GB onboard, so the program can access upto that much "clean" memory all to itself.

Oh and bear in mind there's no particular guarantee that you'll have more working space available for non-code data with 6-8gb in a 64bit system than you would with 3-4gb in a 32bit one, as the code takes up twice as much room, and the system will be compelled to use a larger disc cache and do less swapping.

iRay, at this point, is completely irrelevant and of no interest to me whatsoever, because if I can't render with the lower-end engines, or even get the fucking viewport mode to work properly, then quite obviously I'm not going to get anywhere with that. Plus I don't have an NVidia card anyway, which is its main target and what it will run fastest with. It's something I'd only pay attention to if I managed to get the software working and find I had any kind of talent for the medium.

People were happily making renders back in the pre-Core days, with much weaker GPUs (or no GPU assistance at all outside of the viewport), 2GB or less memory, platter drives with less capacity than my SSD, no 64bit code available, etc, so this really shouldn't be an impossibility or that much of a difficulty for a ~3 year old system that was far from an ultracheap option when bought. SFM particularly I thought should be usable by any machine that can handle the Source engine as-is, and I can play Portal 2 and Team Fortress on here after all...