Show Us Your Bryce Renders! Part 5
This discussion has been closed.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
You can find it at https://helpdaz.zendesk.com/requests/new
Ah, it's not anything like the old system. Unless I'm overlooking something, other than a basic text search which I haven't tried, there are no search and filtering systems like there used to be. It's an extremely basic system where you choose your application, then just type in a single field and add any attachments (or notes later if desired) and choose tech support from the dropdown of who to send it to.
Thanks, I won't be giving up, even if I have to render in several passes and assemble the result in PhotoShop.
However one thing you've said above must be corrected; don't know where you got the information but it is wrong. Bryce 7 cannot assemble scenes anywhere near as demanding on memory as those that can be assembled in Bryce 5.01; not even close. All versions of Bryce are 32 bit and so they are limited to using 3Gb of RAM on the Mac; windows users are normally limited to 2Gb without some workarounds to allow the same 3Gb limit. However Bryce 7 has code in it to compress saved files, but instead of implementing the code in the sensible way, as a pipelined task, the DAZ code compresses the data in memory. That means there has to be room in memory for the compressed version, some workspace and the uncompressed version. This severely limits the size of scene that you can build. In Bryce 5.01 almost all of the 3Gb of memory that it can use is available for your scene, and that means you can import a lot more meshes with UV mapped textures and not have to scale them down. I am hitting memory limits frequently that are much more severe than anything in Bryce 5.01 and it is annoying. The compression code needs to be removed or written properly, disk space is cheap and the ability of earlier versions of Bryce to use more memory is more use to me than saving some disk space.
Ask David Brinnen, he will confirm the above.
I know Bryce very very well as I have been using it since Bryce 3.1 was the latest and greatest version. If I post any statement about what Bryce versions can or cannot do you can rely on it.
I don't doubt you. I know you are experienced with Bryce 5, but not so much with Bryce 7 from what you have stated. While Bryce 5 is nostalgic, continual references to how great Bryce 5 was don't help us out in the slightest. We cannot go back, unfortunately, we can only move forward. The more interest we can generate for the current release of Bryce 7 the more likely Daz will feel inclined to update it. Why should they bother if we are all still using Bryce 5 released by Corel 12 years ago? To my mind, we owe it to Daz to try to make our way with Bryce 7 as a thank you for all their hard work, even if it wasn't all done properly, at least they tried. The only way to get the bugs fixed is to actually use the bugged software.
I should perhaps restate the point I was trying to make earlier. Bryce 7 is a different application in many ways. So I still stand by the idea that Bryce 7 can do everything Bryce 5 would do, but in a different way. The compression is an issue we all hate. Building elaborate scenes as I do, it bites at my butt continually. I'm even convinced it is at the heart of a memory leak affecting instances as well, but I cannot confirm it.
Remember too that the multi-processor support also eats at memory. For a moment they were considering allowing Bryce 7 to use up to 12 cores but it ate away at memory too much so it was dropped. It was costing about 200mb meaning that scenes larger than 1.6gb would fail to save.
I think there is some over emphasis here on memory. Let's assume for now that LAA isnt being used and we are limited to 2gb just as in the old days since the beginning. Let's consider how many mbs the compression occupies. For me in Bryce 6 and up I can construct a scene up to about 1.75gb and still save the file and re-open it without errors. I assume that part of the 250mb overhead is used for the compression process, but also some of it is used for multi-processor support. In Bryce 5 I'm sure one can go higher than 1.75 gb, but probably not by much. Even in Bryce 5 a file larger that 1.87gb could likely run into memory issues. It's hard for me to believe that 120mb or so constitutes a big difference in memory handling. What I'm saying is the cost of the compression isn't that big of a deal. I just don't see how that many more characters and textures could be added to a scene in Bryce 5 when the memory handling is only around a hundred mb in total difference. We are talking about a few percentage points in advantage for Bryce 5. The benefits of the other tools in Bryce 7 more than make up for that loss of 100mb. The fact that Bryce 7 not only has file compression but multiprocessor support and yet scenes can still be built to 1.75gb without LAA is a wonderful thing. I wouldn't trade multiprocessor support for more ram. But that's just me most likely.
Bryce 7 takes some getting used to I admit. But I haven't looked back. Bryce 7 is good for what it is trying to do.
Edit: I should also state that file compression is not itself all that terrible. The Volcanic Archipelago scenes I linked you to cost around 3gb in ram. Compressed, the file size on disk is around 500mb. That is a 600% difference. This matters because like most experienced users, I save dozens of versions of a scene. I probably have over a hundred versions of this scene at various stages saved over the years of working on it off and on. I would long ago have run out of memory on my hard drives if not for the compression.
The problem isn't compression. I don't agree that it is the first thing that has to go in Bryce 8. Plainly, Bryce 8 needs to be 64 bit. Nothing less will do. Seems Bryce is ready to make the jump in most ways, making the failure to do so all the more pronounced. When Bryce is 64 bit and we start building scenes into the 8's and 9's of gigabytes, we will be glad for compression then. I do see the validity of the argument that until 64 bit happens, compression isn't totally necessary for most users. I'm just glad it was there in my case.
You can find it at https://helpdaz.zendesk.com/requests/new
Ah, it's not anything like the old system. Unless I'm overlooking something, other than a basic text search which I haven't tried, there are no search and filtering systems like there used to be. It's an extremely basic system where you choose your application, then just type in a single field and add any attachments (or notes later if desired) and choose tech support from the dropdown of who to send it to.
What that form? It can't be that. It wouldn't make sense to replace the Mantis database with a form. Must be a mix up.
So...
Another loopy thingy. Yet another. Wings 3D project - wings things with loops 3 - by David Brinnen
Bryce first then Octane again. Take your pick.
What that form? It can't be that. It wouldn't make sense to replace the Mantis database with a form. Must be a mix up.
So...
Another loopy thingy. Yet another. Wings 3D project - wings things with loops 3 - by David Brinnen
Bryce first then Octane again. Take your pick.
These are both fantastic, David. Octane wins of course, always, predictably. Bryce versions are always missing light. Transitions from light to dark are always more pronounced in the Bryce renders.
In the Carrara forum right now Phil W is discussing employing Gamma Correction as a means of getting Carrara GI renders to look more like Luxrender outputs. Carrara's GI is substantially more mature than TA currently. But TA is still quite powerful. With some research he discovered that applying the Gamma 2.2 initiates a "linear Workflow" under the hood that corrects all sorts of things bringing Carrara's results very close to those obtained by Luxrender. Testing this ideal in Bryce so far has not been fruitful for me, but it probably could be fruitful in your capable hands. Perhaps you've already traveled down this road? I wonder how Obscure Light behaves under gamma correction? Testing shows it is best to build the scene with gamma correction in mind rather than to simply apply the effect to already established scenes. HDRI backdrops need special consideration as well, they really hate gamma correction.
Here is a link to the thread and here is an image Phil uploaded to demonstrate his findings. I hope he doesn't mind me re-posting it here:
Make Your Most Realistic Renders – Ever!
http://www.daz3d.com/forums/discussion/25644/
sigh, I had originally posted this in the wrong thread, so here we go again.
hopefully I got the correct thread for the post
results of David's Wings 3d ring thing tutorials
@David: Ah, no David, a TopMod tutorial isn't what I was referring to. Though any TopMod tutorial you'd create would be 100% better than those I've seen. And, um, no, I wouldn't like to hear someone else state those things I've said to myself. RE next two images: Love their look, though I agree with Horo the Octane looks blurry, especially the pink colored rings. RE last two images: Both look really great, each for their own reasons. I've have got to knuckle down and give that tutorial a try.
@Rareth: Though a bit dark for my tastes, the object and ground material really look great. The slight green seen because of the light passing through four of the balls is a nice touch. And the ground material really does have that small, uneven, tile took.
yeah it came out a bit dark, experimenting with adding the sun back into it for more light, but I don't want to over do it.
the ground material is actually a terrain using one of David's tricks with the DTE for generating a height map.
What that form? It can't be that. It wouldn't make sense to replace the Mantis database with a form. Must be a mix up.
So...
Another loopy thingy. Yet another. Wings 3D project - wings things with loops 3 - by David Brinnen
Bryce first then Octane again. Take your pick.
These are both fantastic, David. Octane wins of course, always, predictably. Bryce versions are always missing light. Transitions from light to dark are always more pronounced in the Bryce renders.
In the Carrara forum right now Phil W is discussing employing Gamma Correction as a means of getting Carrara GI renders to look more like Luxrender outputs. Carrara's GI is substantially more mature than TA currently. But TA is still quite powerful. With some research he discovered that applying the Gamma 2.2 initiates a "linear Workflow" under the hood that corrects all sorts of things bringing Carrara's results very close to those obtained by Luxrender. Testing this ideal in Bryce so far has not been fruitful for me, but it probably could be fruitful in your capable hands. Perhaps you've already traveled down this road? I wonder how Obscure Light behaves under gamma correction? Testing shows it is best to build the scene with gamma correction in mind rather than to simply apply the effect to already established scenes. HDRI backdrops need special consideration as well, they really hate gamma correction.
Here is a link to the thread and here is an image Phil uploaded to demonstrate his findings. I hope he doesn't mind me re-posting it here:
Make Your Most Realistic Renders – Ever!
http://www.daz3d.com/forums/discussion/25644/
Thanks Rashad, actually, Dwsel is the one to have introduced the topic of linear workflow to our thread. Dwsel, has produced some fantastically realistic renders using this process and using layering and filtering, but it's all a bit fiddly even for me. And somewhat baffling. The long and the short of it, in my view (let me stress that part) is that there is no need to reinvent the wheel here, if you want beautiful lighting, Octane is the answer. Bryce does not have to become Octane, it just needs to talk to it for those people who want that kind of effect. I've looked at the other renders, there are some good ones, there are some great ones, but on balance in the cold light of day, Octane wins me over.
There is a wings 3d widget in here somewhere..
@Rareth: I can't think of any new words to use in complimenting you on that last image. Wow comes to mind several times. Something I wonder about, if you look at the foreground ball support the reflection from the ground material washes out the shape definition of that support. I know that part holding the ball is round, (ish), but because of the reflection it isn't discernible. Or, my eyes might be worse than I realize. ;-)
I think that maybe what the Bryce render is missing is being saved as an HDR file. Then all those black bits would still retain their detail.
Perhaps David could try to do an HDR version or send me the file so I can have a go?
To me, the Octane one looks too washed out.
@David - that new ball thingy has something of a crown, at least half of it, perhaps the colours make me think so. I'm 3with Dave here, the Octane one appears washed out, almost no shadows.
Carrara at version 8 has no means to manipulate the HDRI backdrop, no tone-mapping so they must rely on gamma. It is comparable to Bryce 6.1/6.3 IBL.
@Rareth- Apart from being a bit on the dark side, the ball-thingy looks great. I particularly like the ground. And the "generator" is awesome and the backdrop fitting.
i don't know how to smooth the figure
It appears that you had Anti-Aliasing off. You can switch it on either in the File Menu > Document Setup, or in the Render Options. See mosaic below.
It looks more to me like you didn't allow the render to finish. The top half is markedly more 'smooth' than the bottom half.
you can see the point where you stopped the render.
Hope this helps.
Good skin BTW. :)
Thanks Guss, Horo and David
TLBKlaus – Awesome work, the T-shirts with your abstracts on them are great.
Rareth –both your lovely Wings 3D thingy are cool, love the generator one.
Another Wings 3D loop thingy. Ta render 256 Rpp Hdri – rocks and trees.
Very nice object. Does it have a flaw, one loop seems to be missing. The lighting chosen shows the geometry of the model beautifully.
Lol not a flaw but a few, I rotated the object to get the best view. It was a bit fiddly to select all the correct lines, and I only saw David's note on the video this morning after posting my image.
Thank you for all the comments on the Generator thing,
it turned out better than expected..
I am working on another one, I still have more bits to add, and I still need to find the best viewing angle.
The tubes added complement the generator nicely.
all modeled in Bryce, except for the wings3d object playing the part of the containment vessel.
was so temped to do the tubes in Hexagon, but figured I'd give it a shot in Bryce.
more progress with making bits and pieces for the Generator room.
Indolence, along with an appreciation of Belgian beers and independent bottlings of Scottish single malts will round things off every time.
.
Great progress, all. Always rewarding to drop by the Bryce forum and see what you're up to.
Best regards,
Peter
Heavy Ordnance Brigade, Royal Padded Watch
("We watch, padded.")
.
No we are not, I don't know where you got that from but don't go there for any more information. I'm willing to believe that your careful measurement of 1.75GB is right for Bryce 7, but in Bryce 5 you can use fairly near to 3Gb.
Take a look at the attached image; it's old and yes it's been posted before, but in this case I make no apologies for posting it again. I made this scene when I had access to an older Mac still running Bryce 5.01, but when I started it I used Bryce 7 to begin with, and had no intention of using Bryce 5.01 for this project. There are sixteen figures, and the instancing lab is no use for an image like this because every figure is in a different pose. Two V4 characters with different high-polygon outfits, one M4 character with high polygon clothing, one original Freak wearing a detailed suit of armour, the DAZ troll with his textures, a set with medium resolution textures (most replaced with Bryce procedurals), lots of Havoc figures; they can share textures so they occupy less memory than you would think, though the figure would never be described as a low polygon figure. Once the setting was successfully imported I got as far as six figures in Bryce 7 before it became impossible to save the scene without Bryce crashing part way through. Six.
When I restarted the build in Bryce 5.01 I didn't get a single crash. When building scenes like this it is sometimes necessary to reduce the sizes of texture maps to get everything in, and there are other things you have to do to prevent crashes even in Bryce 5. Import one figure, set up materials, save and quit, then reload everything before importing the next. This is a good idea with any version of Bryce when importing UV mapped content, since Bryce 3.1 anyway (I never used anything earlier). Because I did it this way in Bryce 5 I had not one crash; none; that in spite of the fact that in some cases I forgot to scale down the texture maps. Six figures for Bryce 7, sixteen figures in that scene for Bryce 5. That's the difference, and I don't call that a few percentage points. It IS the compression code that's costing us that, and if you think otherwise you're seriously misinformed.
I still wound up using both Bryce 5 and Bryce 7 for the final render. Because Bryce 7 uses all four processors and my final render was 4000 pixels wide I decided to try loading the final scene into Bryce 7. It loads just fine, though of course you can't save it. Each time I rendered I tweaked the fire materials and then rendered on a quad-core Mac instead of the single processor ancient machine the scene was built on. I now have one of those myself, and it's very nice. It was very nice getting the rendered image so much faster than I would have from Bryce 5, and so I am happy to thank DAZ for the multi-processor rendering.
Metacreations made millions selling Bryce. They were never a large company in manpower, they were smaller than DAZ in fact until Bryce 3.1 came along. How is it that they were able to do that and DAZ can't? Because Metacreations did two things DAZ have never done; they debugged Bryce properly, and they marketed it properly. If DAZ would just debug Bryce properly and keep it in development for long enough to do that, then they too could make a lot of money selling it. Giving it away should never have happened. There are people here who have even tried to help DAZ market the program by putting together a book project full of Bryce images. Lack of interest from DAZ killed it. I could even introduce them to a publisher who would be interested, but I wouldn't do so with Bryce in the current state. It's not some massive problem that takes millions of dollars DAZ haven't got to solve, it just needs a better attitude to debugging and a willingness to listen. Yes, you can do things in Bryce 7 that you can't do in Bryce 5. But on a Mac you can use getting on for twice as much RAM in Bryce 5 as in Bryce 7 before it crashes on any attempt to save a file. I don't know what the difference is on Windows because I don't have access to a Windows system, but I would imagine the difference is very similar if the "3GB enable" has been used.
Not a few percentage points.
Scenes files can be nearly 3gb in Bryce 5 without LAA? Maybe this is a Mac thing, in which case it would explain why it is complete news to me. As a PC user from the start of my Bryceing days the most a scene file could ever grow was less than 2gb. I thought all 32 bit programs were limited to 2gb unless some tool like LAA was employed. Is this not correct?
FireAngel: If your scenes are 3gb big you're doing it wrong.
The scene below built in Bryce 7 (for the June Render Challenge) has over 30 X frog trees, four rhinos, two elephants, four eagles a flock of birds and a V4 with high res textured skin and clothes. The scene file is a tad over 300mb and it's the biggest one I have in my Bryce docs folder at the moment (and it didn't crash Bryce7 once). Even my Stonemason folder hasn't got a bigger scene file even though some of Stonemason's models are extremely complex all with up to 30 different high res textures and bump/trans maps for objects with hundreds of individual components... plus several of them have as many as 8 M4s riding complex motorcycles and volumetric clouds.
Bryce 5 was excellent for it's time... it's time has passed and regardless of the compression issue (which I neither dispute nor agree with), learning how to use Bryce 7 will be more use to you than whinging about it. :)
32 bit programs on the Mac are limited to 3Gb of RAM use not 2Gb, a little more if programmed correctly since they can use 3Gb for data and up to 1Gb for code separately. Few programmers know how to do that so usually it's 3Gb total for code and data. In Windows 32 bit programs can use up to 2Gb total for code and data normally, but there is a way for Windows users to enable up to 3Gb of memory for a 32 bit program if they know how. It is considered risky to do the 3Gb enabling for Windows programs and some will malfunction badly if you do. I am assured that Bryce (all versions since 5.01) can work with the 3Gb limit enabled but I have not tried it so that's hearsay not experience talking.
Don't do it yourself without backing up everything before you do so! If you're on Windows don't do it for any 32-bit application without first checking that the particular program can cope, all it will do is crash a lot if it is one of those not written in a way that is compatible with the 3Gb limit. In addition if you do it incorrectly you'll need those backups straight away. I did it once but had a Windows expert on the 'phone and I do not know enough to advise other than to say be very careful if you wish to try it. Test hard for a few days afterwards and restore the backups if it causes any problems on your system.
As I know you're a very knowledgeable Bryce user I am a little surprised that you didn't know about this 3Gb limit stuff. Google will no doubt find you a few links if you search for "Windows enable 3Gb switch" or some similar phrase.
EDIT to add: Actually "Enable 3Gb switch" followed by your version of Windows is probably a better search, the procedure varies between Windows versions.
Nothing special, but trying out another of David Brinnen's great tutorials (https://www.youtube.com/watch?v=-2pc0NpNHEk) and my own TopMod-like creation modeled entirely in Wings 3D. Working on the tutorial for the model right now and will try to post it over the weekend.
As always, some fabulous creations here! Nice work, Rareth!
Fire Angel,
Thanks for clarifying. I did indeed already know about the 3gb switch thing. But on a Windows system you still need LAA to access more than 2gb for Bryce usage, simply switching alone won't help. This discussion isn't just an issue of Bryce version, this is an issue of Operating Systems and what they allow Bryce to do at a given point in time, which have changed drastically over the years. Most people moved on from Bryce 5 long ago. I personally haven't run Bryce 5 on any Windows OS younger than windows 2000. So for me when I recall using Bryce 5 it was with the limitations of those particular operating systems of the time of which 3gb was not an option yet. The first time I ever touched a scene bigger than 2gb was in Bryce 7 with LAA enabled.
Okay, so if I'm understanding you then you are saying that on a Mac Bryce 5 can access up to 3gb, always could and always should without any LAA. And you have observed that for some reason Bryce 7 is limited to 2gb on a Mac? Bryce 7 doesn't get its 3gb on a Mac in the same way Bryce 5 does? Bryce 7 seems to need LAA to access more than 2gb? If so then I can see what you mane about losing a ton of overhead space.
With LAA, my Windows Bryce 7 scenes can reach up to about 3.6gb. I have never tested Bryce 5 with LAA. I don't even own Bryce 5 anymore and cannot find my disk. Darn it.
If you bought your Bryce 5 from DAZ it may be in your product library, it's in mine along with every other version I've bought.