OK, well, drac did his review of things a couple of days ago, so I had a few hours and here's some of my observations. About a week ago I got a new PC, PIV 3.2GHz wih 2gb of ram and winxp pro. It has a bottom of the line ati card in at the moment, but the card is good enough to run daz studio on it, so I'm happy enough with what it can do performance-wise (at the moment). I'm fairly new to the intricacies of xp and to the implications of hyperthreaded CPUs, so this is also a "this is what I see - is it what others have got/is there a setting that fixes this" as well as some thoughts. BUG KILLING Task bar is damn handy to have it back again. Its kind of odd though that when you move the mouse over the windows task bar at the bottom of the screen that the bryce 5.5 top menu bar thing also pops up. Is that the way its meant to work? I know under win98 and bryce 5 that didn't happen. Softshadows and gel issues - yay they're fixed.

OPENGL This was something I was looking forward to as a really good thing to help with laying out a scene. The opengl is an interesting one. I tested this on a scene that I'm making, so when/if the completed scene eventually shows up, act surprised ;) A - screengrab of the scene when viewed using the bryce 5 opengl setting. This actually looks quite usable and decent for an instamatic sort of large-scale preview. B - bryce 5.5 "Textured shaded", which seems the closest to the original bryce 5 opengl in result - i.e. the glass window separating the office from the rest is transparent the way its meant to be in this opengl option, the way it was in the bryce5 opengl setting. C - the stuff on the outside of the glass through which most of the scene is being viewed. Comparing B and C, the glass that B is looking through really affects the opengl look of that outside area in bryce 5.5. Both the bryce 5 and the bryce 5.5 opengl versions crawled when you moved the camera about in the scene - more than likely due to the amount of stuff the video card had to deal with and the fact that its not a top of the range card. The bryce 5.5 "texture shaded" setting crawled quite a bit slower when you moved the point of view in the scene than the bryce 5 opengl setting, but that would be due to the bryce5.5 one trying to display all textures, not just the default item textures the way the bryce 5 one did. Hence its clunkier feel in bryce5.5 may be understandable given the extra stuff it may be trying to do. The bryce 5.5 opengl setting also doesn't seem to display the lighting from the lights as well as the bryce 5 opengl did. I'm not sure why the two would look so different. Maybe thats a result of the nvidia preference in video cards they're going with. Or maybe thats just what it does now... Or maybe theres a setting in all that video driver stuff I missed.... The other opengl options are interesting, but I probably won't use any of them too much unless I want a specific wireframe image for something.

RENDER TIMES

I test rendered 3 scenes of various complexity and properties.

The first scene was a fairly simple scene - a castle on a couple of rocky terrains sitting in the middle of a water plane with a bit of volumetric fog. Only using the sunlight, default render settings. Its at this link-> http://uqconnect.net/wasteland/g1/stormcastle001a2.jpg
Bryce 5 - 10:02
Bryce 5.5 - 5:55

The second scene is the one used in the opengl demo above. Its not that extreme, coming in at about 20 lights all up and 70MB of br5 file. The textures are a mix of procedural and some image textures, so I call this an average sort of scene. Default render settings.
Bryce 5 - 1:18:30
Bryce 5.5 - 56:01
Bryce 5 on PIII 450 - 6:39:49 (just for amusement)

The third scene was one that had about 30 fully plate armoured knights with some small amount of reflection on their shiny armour in a grassy field (grass was made up of lots of 2d transmapped image planes). This is a heavier scene with a fair few polygons, coming in at about 220MB. Lighting was done with an array of 10 radial linear falloff lights. Default render options.
Bryce 5 - 1:12:57
Bryce 5.5 - 1:40:42

In general, what I saw in the times matched up with what DAZ said you'd see (at some stage) - the biggest gains in render speed are for the smaller files. The third scene however was a lot slower in bryce5.5 than in bryce5. Maybe Bryce5.5 isn't as good as 5 at dealing with lots of transmapped grass objects and the lights going through them and reflections on armour and what not. It sort of makes me wonder if a part of the optimization they did involved playing around with some nested loops in the code, which for small scenes might make them quicker, but when you start getting bigger scenes, the nesting starts to become a hinderance.

The other thing I noticed about the rendering was that the hyperthreaded cpu when using bryce5 simply put all the rendering load onto one of the two virtual cpu's (i.e. one of the virtual CPUs ran at about 100% during rendering while the second virtual CPU did nothing).

When running bryce5.5, the load was shared over both virtual CPUs fairly evenly, but only using about 45% of each virtual CPU. Thus just like bryce 5, it still only used about half of the available CPU power, though now it spread it out. Is that a normal thing in XP with hyperthreading?? - i.e will a multithreaded app only use 50% maximum of the cpu?

Render times didn't seem to be affected whether I had just used an old b5 file or a newly saved from within b5.5 file for the render.

So thats about it at this early stage - don't have the time yet to go brutalize the DazStudio side of things... yet..... any thoughts??

Message edited on: 05/04/2005 09:46

Hyperthreading can't actually increase your CPU's power, it merely tries to facilitate page file swapping betwen the RAM and the CPU's caches. Why you're getting only a 50% processor hit is beyond me. I don't use Intel chips... On AMD chips, anyway, the CPU hits as hard as it can, but XP tries to place Bryce on "low priority" when rendering. You have to manually crank it back up to "Normal", and then leave the Task Manager "on top", as even minimizing it will revert Bryce 5 to "Low". But once it's set in "Normal", it will hit about 98% consistently. This is due to Bryce, not XP. In Maya and Rhino the processor acts perfectly normal. In fact, I often turn Maya down a bit so I can actually do something else, besides watch it's tiles magically appear... The OpenGL preview should look fabulous even on a low-end Radeon. We're not talking about Unreal 3 here. There's no Normal mapping or displacement, and no hardware texturing. Compared to what I'm growing used to in Maya, Rhino, and of course UnrealEd, Bryce's OpenGL settings are a frickin joke. Useless. In Rhino, I can fly around in GL preview with a preposterous 60Hz framerate. And I'm using an ANCIENT Nvidia Geforce 4 MX440, 64MB on-card. My Rhino models are vastly more complex than anything that can be made in Bryce alone, too. DAZ may say they were optimizing for Nvidia cards, but if that were the case they would be using Direct X, and not OpenGL. Why anyone still uses OpenGL for any reason is beyond me, completely. And to be honest, at a glance (and not knowing the scene in question), it appears that Bryce 5's GL preview is much better than 5.5's, although both are total garbage. I'm saying DAZ spent about two hours "updating" the GL code. Weak. A 12-year old dabbler in Half Life code could have done better. From my perspective, Bryce 5.5 is shit. No new features. Minor changes. It should have taken them weeks, not months. Not even A month. I fear Bryce has fallen into rookie hands again... Corel was bad enough. Or were they? (cackles!)

Question...? On the scene that went higher in Render times...? Did you build the scene in 5.01...? If you did you need to turn Off the Gel Light Bug in the Light Lab on every Light,Remember Bryce5.01 saves the Lights with a Gel setting...

"XP tries to place Bryce on "low priority" when rendering" I don't think so. I'm just test-rendering a pic with Bryce 5.5 minimised in background. When I moved it there, the memory usage fell down to 20 MB, but CPU occupancy constantly goes everywhere from 88 percent to 99 percent regardless whether it's in the foreground or in the background. And now the memory usage is climbing and is at 102 MB (should be around 170MB for the scene). You can only see the tab on the taskbar, btw, but the priority is on Normal just like it's for Opera where I'm writing this. Have you set your memory usage to be optimized for programs?

BTW, now I've opened Photoshop, Bryce CPU usage hovers around 94%. I even get 2-3% of CPU idle time. Memory usage for Bryce stabilised around 110 MB. Pentium 4, 1 giga RAM, 1.5 giga virtual memory, GeForce2 Ti 200 with 64 MB RAM (not that it really matters), Windows XP SP2.

I've noticed that when I'm in the openGL texture mode in Bryce 5.5 and I rezize to a large document size for a print quality render it tends to seize and lock. This is the only lock I've ran into. The old Bryce 5 never did this. Keep in mind I'm using a fairly decent workstation ATI X2 card with 256 megs of RAM. Other then that, I'm pretty happy with it for a .5 release. I do think the openGL could be much better. Poser 6's GL preview is lightyears better as well as other 3d programs. You don't really get much of the preview for the textures on objects. It's more of a indicator of the lightning in the scene.

Erlik, I was referring to Bryce 5.01, as I don't have and will NOT have Bryce 5.5. What I said about XP and priorities is exactly what happens in XP Pro, with 5.01. You're the first indication that they may have fixed this in 5.5.

LSD - B5.5, on my machine anyway, seems to start off in normal priority mode. Changing the modes up or down the list of options didn't seem to do anything at all for cpu usage. Must say, I'd not really noticed much difference with rendering speeds with the minimisation... but then does what you're seeing only becomes noticable if you're runnig a second cpu intense task as well as the render? I've seen something like that happen when rendering multiple bryce 5's simultaneously on win2k and win98 - the one thats not minimized gets most of the cpu. I like the bug fixes - they're great for work flow (not having to turn off all those damn light gels - wheeee). Given a good patch that lets/makes b5.5 use more than 50% of the HT enabled CPUs and perhaps adding b5's old simple opengl option to the other opengl options that they've put in would be damn sweet if they could do that :) Foleypro - yeap - all light gels are gone in both cases - I made sure of that, as I'd seen you mention it in a few other threads about the place. The funny thing is I've had a couple of my old b5.01 scenes open without the light gels applied in b5.5, so am wondering if b5.01 saves the scene without the light gel (the way it should) but then applies the errant light gel when it opens a scene back up (rather than saving the scene with the errant light gel). Haven't fully tested that last theory yet. Erlik - yeap. optimized for programs - I've seen that setting in one of my exploratory raids into the xp settings. I've also noticed that those memory usage numbers in the task manager thingy seem to hop all round the place for bryce (and other programs). The total ram used number however seems much more stable and make much more sense. Rathe - I've only had opengl probs with b5.01 when I've been hopping between the various opengl/direct3d/other options.

OpenGL will almost always have some kind of problems since it is directly connected to the processing power of your video card.....on my card, for example I have problems when it comes close to 500000 polys, cuz CPU feeds GPU in chunks, not all at once, so it takes forever, having at least 128Mb (256 would be very good) of on-board ram should help a lot, I only have 64 :(

OpenGL only has problems in programs that aren't programmed to deal with it. My guess is mainly that since Bryce's booleans and whatnot aren't actual geometry, then OpenGL can't actually read them properly and THIS is the nature of it's lag and low detail. Same with the terrains : they aren't converted to polys until rendertime, technically. This follows along the lines of "exportability". I imagine that when they fix one, they'll fix both. Here's a screenshot of GL in Maya. This is realtime, and flows at about 50 FPS on my Geforce 4 MX 440, with 64 MB on-card RAM. This model won't even LOAD into Bryce, much less perform a GL preview...

It's not always transparent like that, either. I was doing a test render using glass in mental ray. Here's what it looks like rendered... Took 4 minutes.

Foleypro - if you should happen by this thread again..... some more thoughts on why that scene of mine may be much slower to render now... I've noticed that the AA pass in bryce 5 really seems to grind to a near halt whenever it would hit a lot of transmapped (like that grass) or semi-transparent things. If the DAZ folk have put in a double AA pass or something like that as part of the "speed up the render as a whole process", then a scene (like mine) that is cruel to the AA end of the render would probably end up going slower than it did before (having to now cope with the bottleneck twice instead of once). Not bitching about it, just trying to understand why that sort of scene would slow down.

Kemal - yeap - 3d shooters rely on minimising polys as much as they can to get that smooth sort of real time animated motion going. Our bryce scenes aren't exactly low poly, so the clunkiness kicks in.

Hmmmmm... Something to Pass on to DAZ...

And how does one do that - not sure its a bug report.... and things tend to get lost in their forums. edit - maybe they could visit here ;)

Message edited on: 05/04/2005 20:11

Waiting for Bryce6...............

I just sent an IM to BryceTech to stop in and give his 2Cents worth... I would also go and put it in the Bryce forums at DAZ,They will stop in and find out what ya need to know...

hey all

lets see..the question about only getting 50% cpu usage on a hyperthreaded cpu....

So the short answer is, ya need to turn off hyper-threading in the OS so it will use the whole cpu.

The long answer? A hyperthreaded cpu uses half of its processing power on one thing..and then the other half on something else. For instance, in Adobe premiere...one half can be used to work on your project while the other half is used to render the previews in the background. Thus producing no noticable slowdown while this goes on. The thing is, a program has to be written to use these. Rendering would gain nothing from being hyperthreaded.

as for the "long" renders...something interesting I have found in this version of Bryce is that premium effects rendering actually renders faster than regular..and this actually produces better results because it actually uses the material data instead of "guessing" at what color a pixel is between while antialiasing. I'd suggest always trying this...I've been really impressed with this new capability.

oh..and last, just a small thought to pass on:
...if enough people "wait for Bryce 6", there won't be a bryce 6. Think about it :)

to each his/her own tho.

:)
and I have a theory as to why some scenes take longer to render. Steve said that they concentrated on parts of the render engine for optimization. Im thinking that somewhere along the line, a variable that should be global and defined early in the render is being defined each time a material attribute is used to render a pixel color. For instance, if you render just using transparency, the speed increase exists for b55, but if you combine this with refraction (for example) it seems to slow down. Just a theory...and tho redefining a variable only takes a millisecond, when you're talking millions, or even billions of rays..that'd add up :)
BT

Message edited on: 05/04/2005 21:17

Thanks for the Quickness...

Aye, interesting news on the material-level AA stuff, though. That's nice to know...

BT - yeah I was starting to suspect the 50% thing may have been an hyperthreading issue from what I've been reading on the web about other peoples problems with other renderers and HT. Thats interesting about the premium render settings. Gonna have to give that a try on those three scenes and see what happens. "millions, or even billions of rays" or trillions or quadrillions... Thanks for that BT :) (and is there any way (someone to annoy a lot) to get the old bryce 5 opengl added back into the 5.5 opengl options - it seems to deal with the lighting in the scene better than 5.5 does).

Attached Link: http://www.alias.com/eng/support/maya/qualified_hardware/QUAL/maya_65_win.html#cards

@ LSD :P Your video card does not even qualify (:P), you can use it, but i seriously doubt that any software can feed openGL card in real time (50fps, or even 25) with scenes which have milions and milions polys in it, as Bryce usually has, with couple terrains here and there (expecialy on gforce4). :D Try to import your castle you made in Rhino into Maya (and I mean full model, no polygon reduction used in Maya) and then test it !!! :P

Kemal... I've been working on this castle for a few weeks in Maya, no glitches whatsoever. The only thing I can't do is hardware rendering, but the only thing you would use this for is particles. The NV17 doesn't support pixel shading extensions, although it all worked fine in Maya 6. Notice, though what else isn't on the list? ANY other graphics cards made in the last two years. So this list is two years old, regardless of what Alias says. They haven't bothered testing any Geforces since my card. And the newer cards, the 5's and 6's, are exponentially more powerful than MY card. So in the last two years, NVidia has updated their drivers... five times? Maybe six. This report doesn't reflect any of these updates on a Geforce level or even Direct X 8 OR 9! Suffice it to say that I have no problems playing FarCry, pumping out massive amounts of texture and T & L data. So a few million polys, untextured as they are in preview mode, are butter in Rhino and Maya. I've never used any polygon reduction on my castle, in Bryce or Maya! At 512 RAM, Bryce just cannot deal with it. Maya has no problems that I've run into, in either it's software renderer or mental ray. Sorry for hijacking this thread or whatever, though...

Hijacking is fine :) When your castle model is in maya - is it in a pure polygon form, or are the curvy bits a special sort of surface that you'd need to freeze before export/import to say bryce - sort of like subd patches where you get a nice smooth curved surface without the need for lots of polys?

Flak, I can probably answer that for LSD. It looks all poly...that curvy bit (im guessing you are refering to the stair case hand rail) could also be nurbs or sub-D..either way can be converted easily into poly But Im not positive that the screenshot is only poly

The screenshots above are all Polygons. No NURBS were harmed in the making of these images! But now on to the castle questions...

I modeled my castle in Rhino, took about a month. That was NURBS, to scale in inches. Then I spent another month trying to make it work in Bryce. It was actually the most tedious thing I've ever done, with either app. And I can't say I didn't learn VOLUMES in this time! After I finally got the castle into Bryce, I started inserting the torches, and hit my RAM limit. (512 MB) The torches you see in the above are just placer radials where the torch groups end up going; the actual torch geometry groups have four radial instead of just one. I simply can't use the scene until I get more RAM, and all I have sitting around here is old SDRAM which won't work in my main setup... Of course, to get NURBS into Bryce you have to convert to polys. The castle had around 300K polys, with another million polys in window-work which I leave out for distance shots. Still, I got about ten torches installed before I ran out of overhead to work with the scene. 20 minute load times, 40 minute save times = unworkable, at this point. Even saving it under a different file name was useless. Bryce needs about twice as much RAM as your scene takes up to function well. Not Bryce's fault, in this case, but my lack of hardware. The imported model in Maya is ALSO "pure" polys. I didn't convert the polys to Sub-D, although Maya has the best Sub-D I've ever seen. I could have brought it in as NURBS, but then I lose my shading groups. I use shading groups much like families a la Bryce, so I can texture multiple pieces with one range of clicks... I'm also more familiar with NURBS in Rhino, which is a much more powerful standalone modeler than Maya in my unexperienced hands. The Bryce scene is 235MB. The Maya scene is 33MB. One of the main differences is that Maya doesn't actually load in your texture maps until you need them, meaning they don't take up scene size when you save the scene because they are just node-links to actual file spots on your hard drive. A big advantage, especially when working with big texture maps (2048 and higher). Also, in Bryce if you duplicate an object it creates an entire new set of vertices/polys for this duplicate, meaning each torch setup adds another 15K polys, taking up both RAM and HD space. In Maya, the torches are instances based off of a "timeline" curve, appearing all in one frame, and thus there is only one set of geometry, taking up RAM only once at a time. With 51 torches x 15K polys, you're looking at another 750,000 polys in the Bryce scene, vs. a mere 15K in Maya. The poly count is roughly the same, around 300K for the main castle. It's design advantages like these that give me more overhead room in Maya to work with. But I actually like the Brycean textures better, and haven't hit that level of detail yet in Maya. I've started exporitng all my Bryce textures on this one by rendering them one-by-one on a large 2048x2048 plane, then using those images in Maya as my texture maps. So far, my Bryce renders are more appealing to the eye, for certain. But they aren't animatable at all, whereas the Maya scene surely is! (render time differences are vast) Now why the hell is he babbling on about all this, you might ask? I'm just illustrating how DAZ could have gone about making certain changes that would benefit everyone, and so far have failed to do so. Optimized Bryce 5 engine in 5.5? Hardly. It's merely a facelift, much like what they did with Bryce 4. The only reason they didn't update the GL specs to keep up with the rest of the industry : They just didn't wanna. For another cross-reference, I'm sure you've all used the Full Tracking shaded modes in Poser 3,4,5, or 6. Have you ever seen anything like that in Bryce? I don't think so! DAZ is just being lazy.

Innovator - mainly the curved wall faces I seemed to remember in his wip shots he put through the forum. Curved faces can generate a lot of polygons if thats how you do it - ask drac and robbie/decobot. LSD - The first serious model I ever made was a castle - it too ended up being a polygon-monster with way more polygons than it needed and in all the wrong places lol. Learnt a lot doing it, and now make much cleaner and more user friendly meshes. Poser (4 anyway) uses references to image textures to keep its file sizes down as well. I see advantages in having everything in your one scene/object file the way bryce currently does it, but the external image referencing would be handy at times ........ as long as you don't go and reorganise your HDD every so often like I do - probably make a nice optional thing to have at hand. As for instancing.... when you do multi-replicating in bryce, sometimes it feels like its trying to do some strange form of instancing - I multireplicated a 1.5MB tree into about 600 trees and the file was still under 40MB... so while its not true instancing, it is "something". Not exactly sure what though.

Aye, but I hardly consider this one a polygon monster! The little glass house above has way more polys than this castle... There are no bunk polys, no errors, and no lost edges. All the surfaces are sealed. There are no booleans in poly mode because it came from a NURBS model. The only curved surfaces actualy ARE the tower shells, so there are 14 curved surfaces (10 and then 1 each for the central-top-tower sides). And these few curved surfaces generate very, very few polys indeed. The Rhino file is only 30 MB, much like the Maya file. It's Bryce itself that is a memory-hog, not my model in this case. But I do understand where you're coming from when it comes to optimizing. This is certainly not my first castle, but it's the cleanest and leanest one I've made to date. Here's my render stats from just now, on a flat-shaded render using an 18 spotlight array and "soft shadows"... Starting Rendering C:/Documents and Settings/Skye/My Documents/maya/projects/default/images/Fortress in Maya_perspShape_tmp.iff. Constructing shading groups. Rendering current frame. Frame triangle count: 145845 ==================================== Resource Usage At End Of Frame ==================================== 138253 Page faults 358.074 Mb Peak total size(Estimated) 128.533 Mb Peak arena size ==================================== 364.930 Mb Current 53.936 Mb Arrays 1.000 Mb NURBS AG 31.250 Mb MEL 0.703 Mb Pixel Map 0.094 Mb File Texture Mipmaps 40.848 Mb Render Cache 0.007 Mb Render Geometry Arena 0.125 Mb Transforms 0.938 Mb Data Blocks 0.125 Mb NURBS Surface Shapes 0.313 Mb NURBS Geometry Cache ==================================== Postprocessing rendering result. Time For Tessellation (hhss): 00:00:00 Time For Shadow Map (hhss): 00:00:00 Time For Post Process (hhss): 00:00:02 Time For Frame Render (hhss): 00:18:35 Finished Rendering. 146K polys aint so monstrous, is it?!? It took much longer Bryce to do a similar render, posted in another thread here awhile back. But it still wasn't equal : equivalent shading would mean a "premium" render, may she Rest in Peace, and hours of downtime... I usually just settle for light arrays in Bryce. Maya lets you seamlessly blend the two on a per-light and per-object level... Anyway, I think I got my point across : Bryce 5.5 is a silly "upgrade" for me, I simply can't justify spending more time and energy worrying over ridiculously long renders and unfinishable scenes...

There is nothing wrong with your Hyperthreading, and you do not need to disable it to fully use the cpu. Hyper-Threading Technology enables multi-threaded software applications to execute threads in parallel. Kinda taking what would otherwise be wasted cycles, and turning them into a virtual cpu. HT and dual cpus are only of maximum benefit to renderers that can run two render processes simultaneously. Such as Cinema, Lightwave, Carrara, which break a single frame into multiple sections, and send each section to a seperate cpu to be rendered concurrently.

Message edited on: 05/05/2005 09:40

Mallenlane - Yeah, in some recent searching I've just been doing, I came across a bulletin board thread that talks about rendering in maya and hyperthreaded CPUs, and they said exactly that same thing.

Heheh, luckily I can run two bryce's with the same scene in each at the same time. Select and render the top half of an image in one, and select and render the bottom half in the other and merge them post render if I want to use every bit of the CPU for rendering (and get the advantage of 100% of cpu rather than just 50%). It should work ok doing that.

Message edited on: 05/05/2005 09:57

. Dang...I'll be back, read more later AS

@ LSD :D I was more refering earlier to realtime preview in OpenGL with textures included, and I took your castle model for example, just to explain problem better (OK, make it 2 milion polycount in Rhino and then play with it in OpenGL :P)... You were saying that you are getting 50 fps with model which has 300000 polys or something :P As you proly know, physical limit your graphics card has is about 30 milion triangles/sec, that would be like 600000 per frame (far less than our average Bryce scene is, wouldn't you agree). If U are having OpenGL preview with textures involved (your model is 30Mb already, for example) I can clearly see how 64 Mb of memory on the video card can be a serious limit :D Another thing is (refering to a scene size) that Bryce saves everything in one portable file (textures included) and all the models are saved as triangles (which doubles any quad geometry, this tesselation happens on import) so if your OBJ model was 30mb, Bryce is gonna save it as 60 (most annoying feature of Bryce rendering engine is that it cannot see beyond triangle)... Anyways, nice discussion, indeed :D

Aye, interesting stuff! To clarify, Kemal : The castle is about 300K polys. Any given shot of it produces about 145K polys at rendertime. If my GPU RAM limit is 600K polys per frame, then it's no wonder why Maya runs so smooth in GL mode! I've got about 455K polys of breathing room... Makes a bit o' sense!

folks, just buy an AMD cpu. Then youll get your %100 usage which is sweet!. but i sure wish someon would answer the question on dual cores. On the rendering side of things im been using 64 rays per pixel setting for every scene now and it fassster. IT seems to love higher settings. Sweet. Al

Yes its great isnt it..

From the cinema4d angle, Intel w/HT renders faster than AMD. AMD displays better during construction windows work. Depends which is of more value to your workflow.

Omac, thank you ser, I've always supported the better hardware though... Proof is in the pudding. I got my castle down to nearly 100K polys, and 'tis more than beautiful in Bryce now....