Jump to content

Alanw

Members
  • Content count

    173
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    1

Alanw last won the day on September 26 2012

Alanw had the most liked content!

Community Reputation

6 Neutral

About Alanw

  • Rank
    Initiate
  • Birthday 07/28/1978

Contact Methods

  • Website URL
    http://www.alan-warren.com

Personal Information

  • Name
    Alan
  • Interests
    Shading, Lighting & Compositing.
    VEX, RSL & Python
  1. Displacement and point cloud

    The file you attached works fine for me. All I did was increase the pointcloud search radius to 0.496.
  2. My comment you quoted was discussing prman 17... I think you may have missed that. I can clarify though. prman 17's ImplicitField SDK has new methods for performing filtered lookups delineated by point p, dPdu, dPdv and dPdw (a filter region). If you want to take advantage of this, then you currently need to be using brickmaps.
  3. Hi Jon, I have only breifly looked at OpenVDB's feature list. From first glance, I don't see any advantages over Field3D. I was hoping it would offer a mip-mapped storage format for performing filtered lookups, but it looks like it also requires point sampling voxel grids. (like Field3D) The Field3D group has shown some interest on the subject at least. I think it boils down to a pipeline decision more than anything. Otherwise, brickmaps are probably the best option for speed and quality.
  4. Try this shader for your clouds. class simple_vol_density(varying float density = 1; uniform float densityMultiplier = 1;) { public void surface(output color Ci, Oi) { color Cdiff = 0; illuminance(P) { Cdiff += Cl; } Oi = density*VolumeField*densityMultiplier; Ci = Cdiff * Oi; } } [/CODE] Be aware, the majority of prman 17's volume related attributes are not supported in Houdini yet. (only prman 16) So you will either have to add them using an include, or modify soho. I wouldn't even try rendering without them. (see Pixar's documentation) It's questionable whether or not you'll actually see any gains in speed. Mantra certainly knows how to render volumes.
  5. Here's a little test. This isn't apples to apples as far as settings are concerned, but more or less the quality of the result. I don't think they're necessarily equal on quality either, but close enough. (The mantra render could use a higher shading rate) I tried rendering prman volumes directly (12.1 supports it), but soho's throwing an error, so all I have to compare with is my DSO for now. The scene has x2 lights. (key + fill), and a voxel grid with (217 325 211) resolution. mantra, using the liquid smoke shader from the material palette. stochastic transparency is OFF volume step size is 0.1 4x4 samples 1 shading rate micropolygon mode Generating Image: ip (640x480) Plane[C]: Cf+Af[4] (16-bit float) Render Time: 1:45.50u 1.86s 5.83r prman, using a custom shader. (just an illum loop w/ density controlling Oi) note the coarse shading rate. (it's the opposite in prman, where 4 is quite low quality) ShadingRate 4 Attribute "dice" "rasterorient" [0] Attribute "trace" "int maxdiffusedepth" [1] Attribute "trace" "int maxspeculardepth" [1] Attribute "trace" "float bias" [0.00999999978] Attribute "volume" "string depthinterpolation" ["smooth"] Attribute "volume" "string[1] refinementstrategies" ["uniformdepth"] Attribute "volume" "float[2] depthrelativeshadingrate" [4 4] Attribute "volume" "deptherror" [0.00392] Attribute "shade" "string transmissionhitmode" ["shader"] Attribute "shade" "string diffusehitmode" ["shader"] [/CODE] Rendering at 640x480 pixels, 4x4 samples "ip" (mode = rgba, type = it) Memory: 2290.08 MB Max resident mem: 718.48 MB Page faults: 0, Page reclaims: 243226, Swaps: 0 Real time: 00:14 User time: 03:00 Sys time: 00:01 Once the buckets appear in my framebuffer, they both take the same time to render (roughly 2 seconds), but my DSO is taking approximately 10 seconds to load the 250MB field3D file for rendering, so all in all I think they're close to the same. Maybe some more folks who've tested both in production can comment. This is with 24 threads @ 3.6Ghz
  6. I've done quite a bit of testing with prman 17's volumes lately while writing a Field3D implicit field DSO. ( a few tests here and I mention render times down in the comments) tests below..
  7. I've fixed a few things. http://www.alan-warren.com/scripts/odforcev8_dark.css - The tags which may appear above posts were illegible. (white text over light gray background image) The tag image is now a deep brown color. - The contents of [code blocks had a white background, with default syntax highlighting. I've updated these to use a dark theme inspired by my current VIM colorscheme.
  8. Another update. http://www.alan-warr...orcev8_dark.css A bunch of the images were still pointing to the old staging URL, but that's been fixed. (I removed them from the CSS since they're not being changed) Thanks to Solitude for mentioning it on IRC.
  9. I've put together a dark skin for odforce that some of you cave-dwellers may be interested in. You can grab it here. In order to use this theme, you'll need the stylish browser plugin for firefox, or chrome. Otherwise, it's useless. To install from firefox, you click "manage styles", and then "write new style". Copy + paste the CSS into your blank style, and give it a name. I've updated it quite a bit, but it's not perfect. If you find any big areas that I've missed, let me know and I'll try to keep it updated, but no guarantees. It's dead simple to do youself if you use the FireBug addon. -Alan
  10. Read me!

    I like the Coders Corner how it is now better than placing Shading, HDK and Scripting a level deeper. I like to skim the "last post info" column from the root level of the forum. If these topics are buried a level deeper, we'll have to click down to see the latest posts. ( I know they'll still be listed @ the root, but it won't always be clear which topic posts fall under) Also, will HDK continue to have ODE, Bullet and Ocean as sub-forums? I like the new look though. Thanks, Alan
  11. Anything would be better than nothing.
  12. Rendering Tons of Points

    This was my "gotcha" as well. Thanks for mentioning this, I was wondering where my output went...
  13. Ptex question

    I think you'll need to stick with quads for ptex. Honestly though, ptex isn't the answer for all pieces of geometry. (especially pieces that you won't subdivide) Mari also makes it possible to get away with auto-projecting your UV's most of the time, so the layout process is very fast.
  14. Render Artifacts

    Can you attach a .bgeo that reproduces this? If you imported this geo with normals present, it may be helpful to delete them and use a Facet SOP to add them back.
  15. Houdini cannot read rib archives. It will only allow you to attach rib to geometry that will in turn be processed at render time. Delayed loads can be achieved with the delayed load procedural SHOP. You reference your RIB on disk and attach the SHOP to your OBJ using the shop_procedural parameter. It's about as simple as it gets. You can also use a standard RIB archive without delayed load. The parameter for this is in the Geometry folder in soho's parameter interface. All you have to do is add it to the geometry you wish to attach RIB to, reference some rib on disk and render. The geometry in your RIB will completely replace the OBJ you attached it to, so it's useful to attach rib to instance points.
×