...for any programmers out there:

Do area render and the small RAM requirement indicate a large chunk of Poser's code has been re-written? Or could area render have easily been written into existing code?

Message edited on: 02/16/2005 16:40

I'm only speculating, Jackson, being that I'm no programmer. However, considering they were able to write in all the modules for P5 over the old code, area (spot) rendering could have probably been written into the existing Firefly code without too much fuss I imagine. That is, providing they're still using the Firefly (REYES) technology.

bookmark. It might have to be renamed REYSBOFHTH Render Everything You See But Only From Here To Here ::::: Opera :::::

As I said in another post, I wonder where they got that idea from? Daz Studio has had spot render for quite a while now, although it was removed from the latest build. It's being released as a free plug-in with more options. Anyway, it's an incredibly useful option to have. Saves a lot of time hanging around waiting for full renders to show up. mac

"As I said in another post, I wonder where they got that idea from?" It's a great feature to be sure, but I'm sure you know it's not "new" technology in 3D. There's a variety of 3D apps that have had area/region/spot rendering years before even D|S came out. It's going to be convenient to finally have it in Poser though. ;-)

Oh sure, I know it's not new, and studio wasn't doing anything ground- breaking by having it. Just adding something useful. I hope CL are doing the same thing in P6 - adding things that are useful. Although, I doubt if 'shadow-catching' is going to be my most used function. mac

I used to use the area render all the time in Bryce. Gee, I wonder who wons Bryce? :-)

Oh, "shadowcatcher" (if it's applied the way I believe it has been) is going to be one of my first reasons for upgrading to P6. If you do any kind of compositing work, or perhaps wish to render shadows as a seperate pass for more post-processing control, which is useful for both stills and video, then I think you'll enjoy having that option. I'm praying for multiple undo, network or distributed rendering, and at least some G-Buffer output control. So far, at least, I haven't heard anything on that stuff. Got my fingers crossed.

It shouldn't require a major rewrite of the code. That doesn't mean they didn't do a major rewrite, just that it's not required in most circumstances. Area render is just passing parameters to the rendering engine on where to start and where to stop rendering by XY display coordinents.

Yeah, Bryce has had plop rendering for at least three and half years now (as an example of a 3d program that's already had it for a while).

"considering they were able to write in all the modules for P5 over the old code..." Yeah, I thought of that after posting. But what about the small RAM requirement? I would hope they're not just BSing like the old CL crew did with P5. "Area render is just passing parameters to the rendering engine on where to start and where to stop rendering by XY display coordinents." Then why didn't they put it in ProPack? Or, at the every least, P5?

I'd imagine perhaps their R&D team didn't think of it at the time, or if they did, they wanted to save it for another point upgrade. Software and hardware companies seem to do that sort of thing all the time. I'm sure, for instance, Intel can develop a 10GHz (or faster) processor right now, but they won't distribute it to the public yet, because they'll make more money selling you everything leading up to that speed little by little. ;-)

Real 3d on the amiga had area rendering before poser or bryce existed. Most 3d ideas are not so new.

thats one of the things highest on the wishlist for P6..srea render...its very very useful. Also...recent files used would be nice..anyone see that ??? and of course the multiple undo...that's been needed since V1 :) The rest of the glitsy stuff can wait...I'd pay $19 for the above 3 :)

"I'm sure, for instance, Intel can develop a 10GHz (or faster) processor right now..."

Just remember to include room in your tower for that liquid nitrogen tank to cool it :-) Actually the dimishing return vs. the complications of raw speed seems to why everyone is going to multi-core instead of just upping the GHz.

Message edited on: 02/17/2005 00:53

Even for a programmer, it is really hard to know how much might have been rewritten. A total rewrite might not be a good thing anyway, since the more code you write, the more bugs you introduce (no matter how great a programmer you are). Better would be if they carefully profiled the existing code (meaning taking measurements as to what parts of the code use the most memory and take the most time) and then "spot fix" the biggest offenders. That way you minimze risk of introducing new bad bugs, but still improve the customer experience. For a new feature, you are also better off making small changes to existing code, so it seems at least reasonable to think that they might have achieved spot render by modifiying the existing code, rather than a total rewrite, but that is probably a good thing. Constantly saying "this sucks, let's throw it away and redo it from scratch" actually produced worse code in the long run than "this sucks, let's see if we can make small changes to make it better". That's also why version 1.0 software almost always gets patched early (because the patch represents that "small change to make it better").

"A total rewrite might not be a good thing anyway..." I would agree in many cases though in the case of Poser, the codebase is so old I don't know. There are apparently still bugs present dating back to perhaps Poser 3 in 5 from what I've heard and I doubt anyone's still around who really understands a great deal of it. Taking all that into account plus the advances in hardware and operating systems on both platforms, I'm not sure this might not be a case where starting over might be the best thing, though we'll probably have to wait for Poser 7 for that in any case. Of corse, they didn't write the core rendering code, only licensed it so I think pdxjims is probably right about it being fairly "easy". But then I couldn't render a .obj file to save my life if it wasn't a method in a com library.

For a core renderer, I don't imagine that advances in hardware and operating systems make a big difference. Rendering technology isn't helped by better graphics cards or a new filesystem or API sets like OpenGL or DirectX (though preview is clearly improved by them). Renderers pretty much come down to CPU speed, size and layout of memory cache, and speed and size of memory. Even if they never touched the rendering code again, they can expect to have Moore's law working for them (the principle that everything in computing roughly gets twice as good/fast/big/etc, every 18 months or so). More interesting is advances in the algorithms, since that's what you'd really want to change if you wanted to "modernize" the code base (as a metaphor, it doesn't matter how many stickers you slap on the side of your Honda...until you upgrade the internals, you're still going the same speed as everyone else). However, such a modernization of the renderer isn't actually necessary to improve user experience. Simply analyzing and optimizing the existing code and improving work flow by way of better UI would make a huge difference. A new renderer would mean new quirks, and as we've seen with Firefly v.s. the P4 renderer, sometimes new quirks block adoption (would Daz be able to sell so much stuff that doesn't use one feature of Poser 5 if everyone were 100% Firefly all the time?) This is all armchair quarterbacking, of course, and I can't possibly know the internal details of what they are choosing to change and what they are keeping the same and why. I can only speculate a bit.

I agree the rendereer is largely irrelevant so to speak, being an entity alrgely unto itself--one reason they could go 3rd party without ripping up too much of the plumbing (probably-speculation as you say). As for the rest, it's a judgement call. Folks like the FAA have managed to keep creaky old code running for decades, ditto all those COBOL banking apps that keep chugging along. At somepoint though, I think you have to bite the bullet as support for old tools goes away and you realize that maintaining, much less enhancing code is so much easier when its implemented using more modern tools and techniques. Of course with Poser, you have the added joy of Mac<->Windows, the technology of which I can only imagine has improved a good deal in the last decade or so. At any rate, better them than me, I'll stick to my armchair and watch :-)

Much as I like Macintosh, the dropping of the mac version would lift a gigantic burden from CL. They don't really "Have" a mac version, anyway. It is not really optimized for OSX. OT: Speaking of old chuggers, I have a really complex manufacturing installation of my production control and accounting software running on a 16-node macintosh network written in FoxPro 2.6 Mac in 1989. The company has 27 employees and grosses 3 million/year. The GL/Inventory control file has 332,432 records in it. It works great. ::::: Opera :::::

Ha Ha Nothing, nothing runs like a Fox! I still have copies of 2.0 and 2.5 (Windows). I don't mourn Microsoft taking the guts of FoxPro and letting it wither though. By the time they kept trying to graft Windows functionality and other features onto the XBase language, it was not a thing of beauty IMO. Between Access and SQL Server, there was never really a place for FP. I would agree with you on the Mac thing but I don't want to get stomped on by the legions of Mac faithful. Besides, MacPoser was there first so it's only right they should continue to support it IF they can do it efficiently. I believe someone said that the quirky Poser 4 .obj export dialog checkbox bug is still in Poser 5 Windows. If that's the case, it certainly seems to suggest that there are some cross platform issues involved. I can't imagine they couldn't fix a dialog box if they were using an OS native interface. Again, please note Mac people, it was Opera who voiced the heresy, not me. I love Mac. Mac rulez. Please don't hurt me.

Bryce had area rendering about seven years ago at least, I think.

Didn't Bryce have area render long before D/S was even thought of?

Can we have a spraycan renderer for Poser7 as well? ps OH look the person above me said it too, that'll teach me for not reading every single post in the thread.

Message edited on: 02/18/2005 08:43

Real 3d had area render before bryce was heard of. It worked similarly to the daz studio area render.

Area render is welcome. CL please don't forget that at this time the render engine, all the Poser software use only 60% of the Intel PIV power! Hyperthreading and dual cpu support, render farm,..., PLEASE. And a french version. Dear dear dear Katherine