Show Us Your Bryce Renders! Part 5
This discussion has been closed.
Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Bryce 7 can access around 3Gb, but only if the scene is built in Bryce 5; building scenes in Bryce 7 is limited to less than 2Gb.
My Bryce7 appears to be accessing 1.75gb of physical memory and 3.63gb of virtual memory.
My Bryce7 appears to be accessing 1.75gb of physical memory and 3.63gb of virtual memory.
I don't know about Macs but on Windows, 32-bit applications have problems when FILE sizes exceed 2GB, this is why the Bryce Libraries need to be watched to make sure they don't grow beyond it as they can be come corrupted,
32 bit versions of MS Outlook had similar issue when .PST files exceeded 2GB.
this is an issue with 32 bit apps and the Windows Operating Systems and memory addressing.
I'm not certain Daz ever sold Bryce 5. They sold Bryce 5.5, but I dont think they sold Bryce 5. Even if so, I did not buy it from Daz I had bought it years ago from the shelf at a Comp USA store here in NYC. I miss the days when Bryce was marketed in that manner.
@fencepost52: That is really a nice little thing, beautiful lit.
@Rareth: I like your generator scene. Looks a bit dangerous - an infernal machine, maybe?
a new variety. Available in any greengroceries soon.
Lit with dome light
That looks incredible. Seriously good. If realism is your goal there might be a few slight adjustments you might consider but as is it already strikes me generally as realistic. The bumps are fantastic!
Rareth,
You are making some incredible strides with this project, and your texturing is masterful. Keep up the amazing work!!
@fencepost: Beautiful object, colors are great. Nice you're making a tutorial for this object.
@mermaid: Hey, great looking object. I had to give it a second look when Horo said it's missing a completed ring. Those little lines can be hard to find, as in been there done that.
@Rareth: The first of your latest images almost looks like a part of an IC circuit. Were it not for the control panel in the second image, that to could be thought of as part of an IC circuit. Both are really nice.
@electro: Awesome looking object, didn't know what else to call it. Guess the ground plane is simulated wood, right? A laminated counter top? Fantastic looking.
I finally got around to working through David's ring thingy tutorial, a few times. I use the ring thingy with three different ground planes, but the one looked to plain. The first one has a cracked mud terrain that has been modified a bit and a modified Autumn texture applied. I didn't like the colors I used the first time so I copied the object from the second image and used it with the terrain ground. I'm showing this one because I liked how it turned out. The second image was a bit of a surprise when it finished rendering. I was trying to find a nice HDRI to use for the background and because the ground plane had reflection added the image rendered as you see it. It to I found interesting so that's why it's here as well.
Edited to add an additional thought: As I was working on David's tutorial, the light suddenly went on and I realized why David was selecting particular lines. And believe me, that was scary. The next time I create something like this in Wings I will know which and where the lines need to be selected.
Guss,
Aww. Good stuff! Impressive in all aspects. Both of those renders are surreal. I feel I could reach into the screen and handle them, but that I would mar them with the filth that still remains on my freshly washed hands, and why ever would I do such a thing? Best left untouched after-all. Beautiful!!!!!!!!!!!
Fencepost,
These are fantastic results! I love the way those rings appear on the plane, very beautiful. The image is very natural looking and inviting. Brilliant!
Mermaid,
Your experiments are beautiful. Please do keep them up. Following the various tutorials is certain to boost creativity. I feel I can see you getting better and better as time passes, getting closer to what you really want with each new tutorial. You're up to date with this new stuff much more than I am so please help me fill in the gaps when I finally have time to start watching and testing.
Fire Angel,
That render is very wonderful, I've always loved it. Thanks for showing it again. On the memory thing, I wish I understood the way the Mac treats memory requests, it is foreign to me. In this regard you and David Savage can probably find more congruence than I can. From the PC User standpoint, Bryce 5 and Bryce 7 seem to be not too far apart in total memory handling, a hundred or so MB at the most. But if its a difference of nearly a GB on a Mac, that would be literally devastating to me. I would likely be as annoyed as you appear to be about it. I am not however convinced it is due to the compression, as there were a myriad of other changes that were made during the development cycles of B5.5 and B6 and any of those less obvious code rewrites could also play a part. If I recall the Bridge used to be opened within Bryce's paging file, maybe the overhead was lowered to make room to accommodate DS 1.whatever it was? I'm just clutching at straws. Beta testing Bryce 7 exposed a sobering reality about how anything new being added tended to break so many previously working things. It was hard to ever nail down how many things would be broken and adequately repaired during a cycle. Compromises were certainly made, I have no doubt. Best of luck finding a way to get as much of it done in B7 as possible. Does LAA work on a Mac?
Savage,
Ah, that render also makes me sick with want for that dream! I only hope to figure out how to get it done like that someday! The plot thicken on the memory front. Thanks for this upload. I;m not sure what to make of it. Those memory readings are quite contradictory. Is the Virtual the representative of the total possible volume allowed for this page, or is it a true measure of the total ram used currently?
Klaus,
Those T-Shirts actually look really awesome. Unlike so many patterns that really are random and meaningless, these designs mange to communicate something. The colors you've chosen take on a new life when considered in 4 dimensions. I'm indeed impressed. This is one of those clever ideas that its surprising more people haven't thought of. Great idea, great imagery. Winning Combo. I suspect these will sell well.
A 32-bit address space can address 4 GB if unsigned variables are used. Compilers have switches to enable LAA right at compile time. It is just a flag Windows checks when launching the application and is a part of the operating system. The progam either runs or it doesn't. No harm can be done to the computer or any other program permanently. I've tested all Bryce versions from 4 onwards and they all run great. Currently, I have set the LAA flag for 16 programs. I have never ever experienced a problem.
As with the memory usage for compression, I'll measure that as soon as I have a bit of time. It doesn't make sense to just claim this percentage or that without seriously measuring it. The task manager in Windows is no help for this.
@Rareth - it gets better and better.
@fencepost52 - that model came out nicely.
@electro-elvis - great fruit, looks very natural.
@GussNemo - oh, they came out nicely.
What virtual memory does and how it's assigned has changed slightly over the years but basically, the programme uses an alloted amount of physical memory (what used to be called RAM chips) and can also use virtual memory too which is a portion of free space on the internal hard drive that an application can use to read and write to as if it's another RAM chip (slower and obviously not as efficient but better than getting an "out of memory" message and a crash).
Theoretically on the Hybrid 32/64 bit Macs (all models made within a few years of the one I use) can access billions of gb of virtual memory (though I can't find a credible report of anyone either doing or needing to do that as an application will only resort to virtual memory when the RAM chip set is at a point where it is 100% in use already).
Of course none of this really relates to Bryce though as it's a native 32 bit application and as such can't access anymore memory than a 32 bit app can access (a little less than 4 gb as the system takes up some of that allocation. Even though I believe that Bryce will make up the looss from abailable virtual memory thereby giving it a full 4gb even is it acts a bit sluggish). How the application then portions out that available RAM to use for it's own functions is down to the programme.
What is most likely the case with Fire Angel's Bryce 5 v Bryce 7 point is that the newer Mac OS that runs Bryce 7 is eating a bigger proportion of the available 4gb and if his Mac is a 32/64 bit hybrid (and he has more than 4gn of physical RAM), he should check to see that he is booting the OS in 64bit mode so the OS has more physical RAM and therefore can leave more of the 32bit 4gb allocation for Bryce to use.
PS: Thanks for the comment about my "Dream" render. I was quite pleased with it, though I did a tighter version and never got around to rending it yet (I missed the competition with it so there was no rush) :)
In other news: Great renders from everyone.
Rareth, your generator is looking cool... or hot with those sparks flying around.
Electro-Elvis: 36 years ago today since the death of your namesake. Intrested to know if you modelled the spikey object. You've certainly got it lit well and the materials look great too.
Guss: You are getting some slick shapes and sharp reflections there, well done.
I've been playing with the X frog trees again. I just did a render that took nearly 2 days (it was a paid job so it's OK, I'll share it here when the magazine the advert is in get's published next month unless I get permission from the client to publish it here first).
This render is just recycling that basic lighting set up, terrain and one of the trees I used. I added V4 steampunk who you've all seen before but who's outfit never ceases to amaze me how well it can look in Bryce.
Thanks everyone for your comments.
Guss- awesome renders. I love the second one.
Revisiting some of the David’s tutorials, and using Wings 3D objects, this is my attempt on David’s http://www.bryce-tutorials.info/bryce-tutorials/pearlescent-paint.html
The second is my experiment with David’s http://www.youtube.com/watch?v=zzB92v1ONJA
@Rashad & Fire Angel - ok, I made a few measurements. The first image has the individual parts identified, the second mosaic can be interpreted the same way. Please check the Current and Maximum values for the top curve (Memory usage). Current is what Bryce uses with the file loaded, Maximum as much as it used for loading and saving. The first (annotated) example has an increase of almost 43%, the second one of 321%, i.e. more than 3 times as much memory was used to save the file than to hold it.
I made two other measurements where saving only increased memory usage by 7.5% and 2.2%. So it depends on the scene and both are right, those that say compression only needs 2% and those who say it needs 20%. I was quite surprised at the results and I repeated the tests several times just to make sure I didn't mess them up.
@All - sorry, this is a bit OT but I think the results are interesting for all.
@TheSavage64 - this is an excellent render. There is some noise in the full size but I understand that increasing the RPPs would have made that render a long afair.
@mermaid010 - the objects came out nicely. In the top render, light and reflections are beautiful. The second one lacks a bit of contrast IMO; the shape, however, came out well.
Thanks all for their comments.
Thank you. I modelled the spikey object in Wings3D. I started with a tutorial of David, lost my path and ended in this object. If someone is interested I could try to make a tutorial. The material uses a curvature filter.
Fantastic. The fruit looks real, though you've done so well with it that it's noticeable that the stalk isn't quite as good. I doubt I would have noticed though if the fruit itself wasn't so convincing.
I'm not certain Daz ever sold Bryce 5. They sold Bryce 5.5, but I dont think they sold Bryce 5. Even if so, I did not buy it from Daz I had bought it years ago from the shelf at a Comp USA store here in NYC. I miss the days when Bryce was marketed in that manner.
DAZ definitely sold Bryce 5, that was the current version when they bought the product from Corel. As I wrote before, it's in my product library though my backups mean I don't expect I will need to download it from there.
Very interesting. I build a lot of scenes with UV mapped imported models that have texture maps applied, and I bet that's the kind of file that needs silly amounts of RAM to save. That's why I have so much trouble.
There's no such thing on the Mac, 32-bit addressing is a simple linear 32-bit space, so in theory it's up to 4Gb. On a Mac any 32-bit application can access as much of the theoretical 4Gb 32-bit address space as the OS will allow. Mac OS 7, 8 and 9 allowed I think up to 2Gb in theory though when they were current it was unlikely you would come across a computer that had that much RAM unless you worked with mainframes or servers, and those systems didn't have virtual memory capabilities. Once Mac OS X arrived the limit was raised but it depends who you ask what the limit was raised to. Some say 3Gb, some say 4Gb. Even asking Apple engineers gets both answers depending upon which engineer you ask. The other answer you get is "You should be writing 64 bit apps by now!" and of course that's true if you're starting from scratch...
OK, progress. I started experimenting with the instancing lab and got a mess of crashes, but using instancing without the instancing lab works a treat. Added a load of beasties and previously each one added about 20Mb to the saved file; however all of the added instanced ones (about ten or more, I forget exactly) added a mere 4Mb to the saved file size. It looks as if this herd will be as big as I wanted without having to render in several files.
Fantastic! Very gad to see you making your way with instances. It is important to know that there is something slightly odd going on with memory when scenes with instances are saved and re-opened. Depending on what you are doing, the true memory usage for instances can be from 400%-700% more than it appears on the task manager during the original session. STill, instances are super cheap compared to real geometry.
@Fire angel
Please ignore. :)
I asked a stupid question that I already knew the answer to.
@Rashad: Thank you for the kind comments. Yeah, wouldn't want any fingerprints on that last one. ;-)
@Horo: Thanks so much.
@Dave: Thanks. That lady of yours is looking mighty fine. You seem to be having fun with her...he says with a straight face. I tried a few of the Xfrog trees the first time someone mentioned them, but when I imported them into Bryce the leaves were squares, just squares. Haven't used them since.
@mermaid. Thank you. That's a really nice image. Reflections and shadows are nice. The flatten sphere(?) reminds me of a pool of mercury.
@Fire Angel: Someone going to have a problem walking across that area after all those beasteys pass by. Or is the guy with the broom and shovel following behind? :lol: It's really looking nice.
Fantastic! Very gad to see you making your way with instances. It is important to know that there is something slightly odd going on with memory when scenes with instances are saved and re-opened. Depending on what you are doing, the true memory usage for instances can be from 400%-700% more than it appears on the task manager during the original session. STill, instances are super cheap compared to real geometry.
One of the signs of a good implementation of instancing in a 3D program is memory use jumping up and down during display and render operations. That's probably something that task manager can't keep up with, so it will show inaccurate figures instead.
Yes, Guss, like most things that use trans maps, they do need a bit of sorting out before being useable, but it really is worth the effort as they are really nicely made, even if a tad render time intensive. :)
It takes a moment to put in transparency for all those square leaves with UV maps but I think it's worth the time. I had downloaded 167 trees and adjusted all leaves, then saved the trees in the objects library. Now I can use them without further labour.
Following them might not be a great idea even if you have a large rose garden; they might interpret your actions as stalking one of the babies in the herd and that could be very bad...
In case you decide to try again, here are some old notes I have lying around from the last time I did conversion. The instructions may look daunting, but it's actually really easy to do (just hard to read). Once you do two or three you'll get the hang of it and zip right through them all. Only thing is if you have a bunch to convert, you'll need to set aside some time to get it all done, but after that you'll never have to convert them again.
Here are two workflows I have. The easier one is just importing directly into Bryce, the harder one is importing into DAZ Studio and resaving as .duf so they don't reference the original files they were imported from, allowing them to be categorized along with the rest of the DS content and sent over the bridge from DS to Bryce. (warning, old instructions, unverified, might need correction.)
IMPORTING INTO BRYCE:
When importing Xfrog plants, the transparency will not be set correctly for leaves which will show up as squares with the leaf image on them. To fix, select the meshes for the leaves (there may be more than one, they can all be shift-clicked if you want) and then press the M button to edit the materials. In the Transparency channel (not the transparent channel!), move the blue marble from the left to the channel that is being used. TODO VERIFY-->Also click on the Material Options flippy triangle and check "blend transparency", which is necessary to eliminate a faint ghosting of the same problem that may not be immediately visible except against certain backgrounds.
IMPORTING INTO DAZ STUDIO (to categorize content and allow them to be sent over the bridge to Bryce):
bring the xfrog objects into the content manager this way: One of the two DVDs for each product has the .obj (except for tropical which is on the only DVD.) Create empty folder "C:\sean\3D graphics\objects\xfrog " with a subfolder "custom materials". Copy entire original folder's contents into "custom materials" so image references don't point at backup folders.
Make .jpg copies of the leaf and bark textures (just because it takes up less space than the tiffs). Make an inverted (black to white) copy of the black and white leaf picture (Gimp: Colors > Invert) filename prefix "inverted ". (There may be extra unused tiffs.)
---
In DAZ Studio:
In the Content Directory Manager, map the folder (BEFORE any .daz scenes get saved, so all texture references are saved relative and not absolute.)
File > Import and browse to the first of the 3 .obj files. Copy the filename to the clipboard, then double-click on it to load it. In the OBJImportOptions window, change the From dropdown to custom, set the scale to 1000%, and the the Depth(Z) dropdown to Y .
To get transparency to appear correctly, In DAZ Studio's Surfaces (color) tab, set the Diffuse Color texture dropdown of the leaf and the bark to their appropriate jpgs. For the leaf surface, set Opacity Strength to the inverted leaf picture. For the bark or anything with a *_b texture, set the Bump Strenth image to this. TODO CURRENTLY THE VALUE IS LEFT AT ZERO SINCE I DON'T KNOW WHAT'S CORRECT. I'LL HAVE TO SET IT WHEN I NEED IT PER ITEM.
Make sure the entire object (not just one surface) is selected then frame the object to get a good thumbnail when saving, then File > "save as" > "scene subset" so it defaults to merge instead of replacing what's in the scene. Paste the copied filename and save in the top level folder.
If there are additional textures such as an autumn leaf color, repeat and save as some descriptive duf.
Repeat for the other 2 .obj files. After all three versions are created, delete everything but the jpgs.