Firefly isn't specifically the problem, the main issue is Poser itself and the manner in which it sets up data for whichever renderer to use. I haven't specifically measured the relative memory overheads between P4 and Firefly, but I would expect that it's relatively trivial.

This isn't a new issue I and others have been posting and writing to CL/EF about the declining capabilities for at least the last 5 or 6 years; since ProPack was out. At that time it only affected a minority of ambitious users but, throughout the intervening content and code releases, the decline in capacity has been predicatble. The only difference with P6 is that the problem now affects a larger proportion of users.

Over the last year I've had some correspondence with the developers at EF and I am aware that at least now the problem is being recognised. It's unfortunate that I got the impression that prior to this (in the coding of P6) they didn't have any awareness of the issue despite the fact that it had been often raised in these forums.

On the subject of the large memory aware/64 bit compilation idea (svdl and Khai) this is a bad line to be taking and one that fails to directly address the issue.

The problem is still a bad 32 bit design, not a limitation in memory. Allowing the users to throw more memory into the pot (at their own expense) to support the existing excessive resource usage is going to only provide for a gradual improvement tempered by any increases in the complexity of the content that they expecto to use.

For me I'd rather see EF expend their resources in producing a 32 bit version which can handle a couple of hundred or a couple of thousand figures in a year or two rather than get a 64 bit recompilation that may be able to handle a couple of dozen figures sometime in the next decade.

My main problem with this idea is that EF may take the recompilation idea as quick and dirty way to extend the life of the code without fixing it.

Bill