Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

paul

Members
  • Content count

    54
  • Joined

  • Last visited

Community Reputation

0 Neutral

About paul

  • Rank
    Peon
  1. Very late reply - but I had this thread open while looking into RHF sampling. I've some additional info from Sesi which I'm going to share - just in case someone else stumbles upon this thread like I did. > Hi Support, > > Rendering with the combine-20 (histogram) pixel filter seems to be very > slow even on black / empty space. Is this a bug or feature? Hello Paul, Our developers tell me that this is a known issue with the "Ray Histogram Fusion" filtering approach. The original paper only presented results with images up to 1280x720 and a single image plane, where all samples can easily fit into memory. However, with a 3840x2160-pixel image, with 8x8 pixel samples, that's 530 million samples, and with 16 image planes that are each 4 components, that'd be over 126 GB (3840*2160*8*8*16*16 bytes) to keep in memory, and the results couldn't be shown until the render was completely finished. With more image planes, more pixel samples, or higher resolution, it'd be even more memory. Since it's not feasible to reserve that much memory just for keeping sample data around, we have to filter one tile at a time. Because RHF with its default settings can have an output tile depend on rendered sample tiles a few tiles away, even that can become a lot of sample data to keep in memory until it's no longer needed by any output tiles, so it may be explicitly sent out to disk if the sample data cache limit is reached. However, the biggest issue performance-wise is that, because the filtering is done one tile at a time, and each output tile depends on a lot of sample tiles, there's a lot of computation that has to be re-done for every output tile that would have only needed to be done once if the whole image were filtered at the same time. This isn't a significant issue for the default Gaussian filter, because a pixel can only depend on samples that are one pixel away (both horizontally and vertically), so there's very little overlap in computation, whereas a pixel in the default RHF filter can depend on samples that are 40 pixels away. The performance of both filters is independent of the content of the tiles, apart from the number of image planes, pixel samples, and image resolution, so for more expensive renders, the filter time shouldn't be as significant, but RHF will require that *much* more of the image has been rendered before the first output tile can be displayed. The other significant issue with the RHF filter is that it will eliminate some noise in an image even if it's supposed to be there, e.g. from a texture map or displacement shading, not just noise that is due to undersampling. For example, if you render the mantra_Combine node in the scene submitted with this bug, you can see that a lot of the detail of the mandril is removed, whereas the Gaussian filter keeps the detail. Most of the example renders presented in the original paper either didn't have noisy surfaces or had noise that was well above the threshold value they chose, so this was only slightly visible in a few of their examples.
  2. Fantastic. Many thanks Roman - kudos to you. If your in London - we at Realise will like to buy you lots of beer! I see there's a lot of interesting optimisations available. I haven't had enough time to dig deep - but how compatible would you say this is with the Disney plausible shader? I'm asking, as there's lots of interesting software that compliments the Disney model - and I'd be keen to explore how your shader could fit into that workflow. Again, thanks from all of us. Cheers, Paul
  3. ok - some points: - ensure that mantra rop/shading/colour space is set to Gamma 2.2 - so that variance is working most in "eye" colour space. ie, smoothing out the dark bits - use portal lights - make use of photon maps (indirect light). reduces noise. sidefx *really* should have a "best practice" selection of demo hip files which have all these settings tweaked to production perfection. -paul
  4. hi all, here's a techy question: has anyone ever managed to get a linux-houdini to run as a guest OS in a virtual machine in any form? i know that there's has been issues with linux, OGL & nvidia drivers in the past. but it's 2012 - and maybe things have moved on...? AND i'm also interested in hearing about things from the opposite point of view. ie, any luck running OSX (hackintosh) or Windoze as a guest OS on linux with proper 3d acceleration. ie, running decently 3ds max, or final cut, or CS5 in guest OS's. i'm hoping that things may have moved on since i last looked at this... regards, paul
  5. hi - i've just had a look at this - and it looks v interesting! has anyone had a go yet? keen to hear of any experiances....
  6. late reply - but just catching up on this forum. i know for sure it was hand animated in lightwave. we're currently working with the same director (and i've known him for 10+ years). v nice chap - and thinking about learning houdini...
  7. yeah - lovely work guys! also agree with peter - lets have dynamic splash (as an option of course) with the best render submitted to sesi changing every 6 months...!
  8. sure- i think i'm in total agreement with you here! just something that gives us the same ability as rpm managers like yum. ie, each asset will have a tab - which lists all the assets (and version) it current depends on. then, we could tweak this list - and add (==, <, >=, etc. for each dependency ). also, the ability to pack/publish an asset with all it's dependent assets to a .otl file. the only other smarts that would be needed is the ability for houdini to have several versions of an asset in the search path - and to load in the correct one as and when needed. (hope i'm clear here). this would enable high level "meta" tools to be published with ease! btw, when i mean assets - i *only* mean houdini .otls. certainly not textures, bgeos etc. etc.
  9. i disagree strongly with this point. why: - if it can be done VERY quickly - then sesi should do it, very quickly! - sesi is wanting smaller studios to get into houdini. give them a basic way of handling dependences. and, from what i hear - most shops handle this very badly. (...apart from core so i hear!) - it will make publishing assets that themselves depend on other assets possible. currently, it's a nightmare to manage this with vanilla houdini. this will stimulate 3rd party community 'higher' level assets. - my major point: right now, managing DA's feels like managing rpm's in pre yum/smart/apt-get linux days. look how linux's usability sky-rocketed once automatic dependency handling was integrated into distro's. if it's easy as you say - sesi should at least set a basic standard for everyone to follow. :-)
  10. hey sy, i think we're in agreement really. i often like to use the inline VOP - or hand roll code in my own assets. i think the main thing i'm trying to say is that i think they are already v messy- and need to be tidied up. i also agree that loops and sub blocks make anything with control logic almost unreadable. ie, your shader is scattered deep in many subnets. i gave up using them years ago - they're awful - but could/*should* be improved! one suggestion is that the for/while loops to have a begin block node, and an end block node. it would flatten the structure out - and make it much more readable. quite like the good ole shadetree really! or, create a loop with a network box that has inputs and outputs. there are many ways vops could be make clearer. setting standards for seeds/manifolds would go a long way to formalise vop interfaces. btw, i always prepare my own gather loops using the inline. however, its a pain - cos i cant use any of my other vops within the code. ugh! in summary: - clean up the loop structures - provide better higher level vops (which could plug together to make an ubershader toolkit) - fix wiring (names rather than index's) cheers, paul
  11. hi all, here's my houdini 10 wishlist/rant: 1/ rendering/lighting. open up the power of mantra to less techy users. ie, - better default shaders. the current ones (even the newer ones) are a complete mess. look at the networks - disgusting! houdini is competing (and loosing badly) with the competition here. a real *production ready* shader library. ie, optimised uber-like lights, glass, metals, car paints, all with proper arb-outs (to a standard). we dont need things liker red carnation (wtf!!!) - just a good solid base that can be built on. give people a couple good uber shaders made up of these components. this will *increase sales* if novies can pick up houdini and get beautiful renders out of the box. - revamp vop library. again, this is a mess. some patterns need st others P, etc. etc. create a manifold type. vops need to reflect how we now work in production. - vops should wire to names not input numbers - fuller vops to reflect all the mantra functions. ie, gather has no else! crazy! vops badly needs lots of love. - better rendering in viewport. faster, IPR, workflow needs to be better. - in short, new artistic users should be able to get look looking setups as easily as possible. there's sooo much power locked in there - it needs to be unlocked. 2/ better UI. currently the wiring in houdini sucks. look at nuke/flame/all the other programs out there. houdini should be a joy to use - rather than an exercise in frustration. there's lots of good ideas out there. please, lets get this sorted. again, first impressions count, and h9.1 feels "clunky". (and you guys were first on the market with the node based workflow!!!) 3/ network boxes with comments - a long requested rfe. please, it's so simple and would help so much! there's loads of other simple rfe's out there that'll just give houdini some badly needed production polish. 4/ rendertime particle fluid surface. whats the point spending all this time writing fluids if we can only render them in sops! please, this is essential...! 5/ improved documentation. again, no point spending all that time writing all that amazing code if no-one understands how to use it. 6/ improved examples. ie, currently the shelf flame is terrible compared to fumefx. the built in tools need to be better than the competition? 7/ keyboard shortcuts. just saying you can bind your own keys is a real cop-out. (sorry jeff! ;-) ) houdinis' UI should ship optimised. avid doesn't sell it's editing software with a mouse only UI - (and expect users to create their own). the keys have been carefully thought out to teach new users good practice. the fact that h9.1 doesn't have decent keyboard short cuts thought out from the beginning says a lot about how the new "UI" was "designed". 8/ node widths. still not working - takes too much space. still needs fixed. why cant that space either side of the icon be reduced? etc. etc. etc. need i say more? 9/ digital assets to have built in versioning and dependences. a la rpm/yum/smart style management. this is so important to enable us to build long lasting assets which depend on other assets etc. etc. would help us all to publish meta-assets to remote users, the community, sesi support etc. ok, that was bit of a vent, but one of my last really. going over old ground too many times. most of these things are either long standing rfe's or big issues from the 9.0 alpha. personally, i hope that 10 is more of a polish/workflow release. on a positive note - i love houdini to pieces. it's the best - ra ra ra! :-) reagrds to all, paul
  12. Here's my wish list for h9: Mantra: (haven't used intensly for some time, but I do believe these are still outstanding) - gather() construct a la prman. With the ability to pass parameters to shaders before they are evaluated. this would make writing shaders x100 easier! - ability to write out point cloud data/occulsion/irradiance caches on a per object level. this is also of vital importance. Similar to prman's: Attribute "irradiance" "filemode" "w" "handle" "$MAPS/occulsion_cache/$OS.icf" ie, this can be specified either in the shader OR in the rib stream. Very very useful for complex scenes where you want to reuse 90% of the static points and only recalculate the objects that are moving. - is anti-aliasing finally "fixed"? - speed up occulsion/irradiance. Does mantra have importance sampling yet? Assets: - rewrite how vop definitions are stored. Right now, there is a severe architectural problem with DA's in general. There is currently two ways of creating them. The VOP way, and the rest of the system. The VOP method is correct, embed the definition within the asset itself. The other way, a seperate definition in the VOP context is an unnecessary extra step. This means that it's hard to make a self contained asset with it's own sub definitions - as having several of them also means you have several definitions of it's sub assets. A real mess! This is my #1 Houdini 9 wish. - asset manager. need a rpm style versioning with auto dependencies. I'm not talking about a full CVS style versioning which I think is just not needed. Just a more granular asset A version 1.3 needs assets B(v.2) C(v2.3) & D(v3.4) in order for it to work. This is not a biggie to write - just some low-level management stuff. DA's are a great start - a proper asset mangement system would add x100 value! Cops: - make it work - 2d tracking (cmon sesi, this has been outstanding for >5 years...) just buy it in! Regards, Paul
  13. Thanks Mario for sharing. Very interesting indeed...