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.

symek

Members
  • Content count

    1,811
  • Joined

  • Last visited

  • Days Won

    64

symek last won the day on August 2

symek had the most liked content!

Community Reputation

261 Excellent

2 Followers

About symek

  • Rank
    Grand Master
  • Birthday 09/26/1975

Contact Methods

  • Skype
    szymon.kapeniak

Personal Information

  • Name
    Szymon
  • Location
    Waw/Pol

Recent Profile Visitors

20,551 profile views
  1. If you have a choice you could try FBX, which supports basic materials. You could also look around as there were a couple of MTL parsers for Houdini around. It's a trivial task if you know a little Python. Unfortunately Houdini is hardly used in a scenarios where obj files with mtl becomes handy. Also most Houdini materials seriously overcomes MTL specification.
  2. Houdini OBJ importer actually supports materials assignment, it just doesn't import / create them based on mtl files - you can spot a primitive attribute shop_materialpath pointing to something like /shop/Material_name (as found in obj file). Importer doesn't touch mtl file though, so materials have to be created manually. Note also that materials assignment inside OBJ file itself is based on primitive groups, which also end up in Houdini, so you can assign new materials based on those groups rather than rely on per primitive attribute.
  3. Considering how PTEX ignores entire ecosystem of assets creation, and how game originated tools heavily relying on UVs, reinterpret those assets pipelines without f*cking it, it's hard to believe PTEX has any future as long as a plain polygonal geometry is involved.
  4. Well, despite of the warning about VEX not supporting animated parameters, for years placing $F inside a shader body simply worked. There is a subtle nuance here though, and it't hard to see, since GUI wise all Houdini parms look the same. There are two different things involved here: shader's variables (inputs inside Shops/Vops) and parameters on a nodes. Basically think about Vops (material builder or anything involving nodes and vex) as a pure string based code generator. Code listening will be generated inside Houdini, but interpreted in a different context (inside Mantra), so expressions (usually evaluated inside Houdini) don't fit. Promoting them outside a shader body, allows them to be correctly evaluated prior execution (passing the result to shader body as plain old data variable). Seems like different types of Vops involved subnets has different opinion about what is possible though.
  5. Very few research papers fit to immediate implementation. The unfortunate side effect of the citation system (JIF) is an urge of frequent publishing among scientists. It renders a plethora of research with questionable value. They usually indicate general research and progress towards some new possibilities. What is actually implemented few years ahead is a common middle ground different scientists have made available for practitioners. Some exception might be the enhancements to the technology which is already in use like, say, XPBD for Position Based Dynamics.
  6. Since you're tracing over second input's geometry (?), tiny correction is needed (note first argument); i@intersected_prim = intersect(1, v@P, direction, new_position, u, v); I would also recommend initializing new_position, u, v for extra safeness (it used to be mandatory, not sure now). hth, ps sorry also for previous criticism, I didn't notice that naming convention isn't actually very clear in that case.
  7. in SOPs: intersect() in surface: rayhittest() or trace() Just a friendly remainder, that it is generally recommended to use docs page before asking basic questions on a forum
  8. My God! I was again years ahead of time.
  9. That's the whole point and the problem SESI is facing as much as I understand. Cops engine would require serious rewrite to make it reliable. Personally I don't mind its current limitations features wise, just make it work for +2K resolution with +10 layers of multi-raster images is a obligatory requirement before going further. I'm afraid this is not something SESI is willing to undertake (and neither most of the users would appreciate if that would caused slow down of 3d development).
  10. I'm kind of lost here. If you have a deformed mesh you want to instance geometry onto, why not to scatter points on it in SOPs, and send them to mantra for typical instancing with packed primitives? Houdini can easily handle dozens of millions of scatter points in a viewport. Anyway, if I understand you correctly, you can do what you want with HE Procedural Shop, which allows you to generate meshes (also packed prims) at render time. So, in the example above: 1) append copyToPointSOP to HDA output (instancing some geometry onto points) 2) replace HE Point Generation with HE Procedural with the same setup 3) add -e full to mantra command (Rop's driver tab) and you will have meshes instanced on a points scattered at rendertime on a mesh, which is awesome all together, but mantra will consume hengine license. does it make sense?
  11. Does your geometry have uvs? This plugin generates a set of textures from a substance material and applies standard Houdini material to the object in question with those textures applied on it. Another issue might be the path Substance trying to save textures to. Make sure write permissions are in place. hth, skk.
  12. Feed FileSOP inside your HDA with something like op:/`chsop("../mysoppath")` (mysoppath being hda parm). Point attribute should point to mesh you want to scatter onto, with render visibility set to None, but render flag turned on, so that a mesh will be exported to ifd.
  13. Haven't looked into your example, but this one works here. You need hda which generates only points, and procedural applied on a geometry to instance your hda on. Point's attributes overwrites asset parameters. Haven't used it in production yet though. hth. HEPointReplicate.zip
  14. Just use GetAttribute VOP inside Vopcopfilter. Set Geometry File parm to op:/obj/mygeo/mysop and compute point number from current pixel index (IX+YRES*IY). Alternative approach is to use sopGeo.pointFloatAttribValuesAsString() and cop.setPixelsOfCookingPlaneFromString() inside PythonCOP, but requires little Python magic (actually while stepping on a Python tail it might be easier to save, say, numpy array as image file (google it)). hth.
  15. There was a Charlie and Rayz (by Silicon Grail), with the latter one using Halo technology licenced from SESI, they were much more serious about compositing than SESI ever was even before Nuke was released. Halo has lost with Shake mostly (not to mention binding compositor to HDK with all its limitations back then, wasn't very promising idea).