Skip to main content

PBR fun

Just playing around with PBR, also was reading about linear colour space so I was also experimenting with doing a sRGB > linear coversion to the textures -- before .rat creation as the mipping is wrong in sRGB. A 2.2 gamma is applied when viewing the render in mplay and also applied when saving a .jpg. I understand it all a little bit better now, that workflow seems to work alright.

Just used the Galileo's Tomb HDRI from http://www.debevec.org/ with no other lights.

hipnc file is here

Comments

  1. Dope Shancock... Is the mipping in sRGB wrong for both .rat and .tdl files?

    ReplyDelete
  2. I guess so, it needs to be resampled in linear to work properly, but I don't think it is a super significant problem. This site was good at laying it all out: http://mysite.verizon.net/spitzak/conversion/

    especially these pasges:
    http://mysite.verizon.net/spitzak/conversion/composite.html

    ReplyDelete

Post a Comment

Popular posts from this blog

Some SOPs edges and poly line business

Every time I go to extract the border from a mesh I always end up using some strange combo of Group unshared edges, delete and dissolve, I came across a good way of getting unshared edges that I haven't thought of before, and now it seems really obvious ... using the polycap node to trace the border and then deleting all of the source prims, works like a charm! I have also usually had trouble with splitting up a line into multiple primitives, here is a way to create a primitive per edge. This example only works if every point has 2 neighbours but could easily be modified with a copy SOP to allow a dynamic amount of neighbours. (instead of 2 vopsops and a merge to duplicate the points). It works like this: The point number is stored in an attribute to create a unique number for each point The whole mesh goes into 2 streams to duplicate every point. For the first set of points, each point gets the point number of the first neighbour and applies a cantor func...

Worm locomotion with FEM

I have always wanted to do a dynamic locomotion setup, I have tried in the past with wire and sop solver with .... interesting results ;) With FEM in Houdini 13, the rest attribute is stored on vertices which allows a tetra to change its rest state independently of the surrounding tetras. With this, parts can be expanded and shrunk to get a muscle type action. I have started with a worm since it is quite simple, the contractions and expansions move back along the worm in a wave, opposing the travel direction. It took quite a bit of tweaking to get him moving at all. One major element of a real worm's action that's missing is the little hairs that grip the ground. I couldn't find a way to change the friction per point so I have gone a bit hacky and multed down v wherever I didn't want the worm to move. I would love to hear if there is a per point friction control! Here is the video Houdini 13 FEM Worm locomotion from Sam Hancock on Vimeo . ...and the .hip is...

Wire to RBD feedback in DOPs

Normally if a wire is constrained to an RBD, the rbd isn't affected by the wire at all. Which is annoying ... but I had an idea to get it to work. the wire solver can store the internal forces on the geometry. In DOPs I made a point force, the position is set to the position of the constraint and the force is the wire's internal (linear) force. I have put a sopnet in the dopnet to get the wire and the constrained point so I can reference them in the point force. It could be simpler with a python expression to get the position and force directly without going through the sopnet, but this is just a little test... For multiple attachment points, I think a copy data node could be used to copy the point force data for each constrained point ... hip file here Wire to RBD feedback forces from Sam Hancock on Vimeo .