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.

acey195

Members
  • Content count

    347
  • Joined

  • Last visited

  • Days Won

    7

Community Reputation

76 Excellent

About acey195

  • Rank
    Illusionist
  • Birthday 01/10/1991

Contact Methods

  • Website URL http://www.twandegraaf.nl/

Personal Information

  • Name Twan
  • Location France

Recent Profile Visitors

5,477 profile views
  1. cool idea! About your work.. if it is the same type of stuff as what you would normally do with Houdini, you could code inside Houdini of course VEX, Python, OpenCl, take your pick!
  2. You can actually save your visualizer settings as default and from H15 (or H14 even) on you have the options to save both scene and global based visualizers. edit: Ooh, got ninja'd with the launch event, pretty neat!
  3. Python and VEX go a long way :P. but basically everything in Houdini is datamanagement if you bring it to its lowest level.
  4. Well I guess, its also the usage of Houdini as a pipeline tool, managing data, rather than outputting pure visuals. And yeah outputting stuff in a way that is compliant with other existing technology, which sometimes means you are more limited in how you solve a problem, exporting rigs from Houdini directly into game engines sounds pretty challenging for example, but some animations baked into bones or vertices are more likely to work. Also personally I almost never even touch DOPs . Though others do use it for baked destruction, cloth and water in games.
  5. Haha, well yeah but I don't think the general (gaming-consumer) public will be really watching that talk though. Whereas some people will watch first hand videos on game technology, if they end up on Youtube or something somehow. So I think you are safe from Sesi in that regard :P.
  6. I think you maybe shouldn't put the $SLICE inside the ``, as it is a local var and will evaluate to a string already I think. It does when you start your file path with $HIP for instance
  7. yeah I know there are still alternatives, but they get more and more forced I mean if you would use that term to me, I would only get that you were referring to procedural the 3rd sentence into our conversation. others would be "systemic" or "based on rules" but it kind of saddens me we have to kind of skirt that, but I guess we shouldn't really go too much off topic
  8. Yeah I do understand that I suppose, I guess you can just swap out "Houdini", with "The procedural solution we used" every time in the presentation, but that does become quite tiring after a while possibly :P. On the other hand, there now also exists some uncertainty with game marketing, because of what happened with some indy-game procedural tech recently, so they want to avoid using the term procedural altogether too... So where do you go from there? Use algorithmic as a term? Possibly, but that is also already pretty close to a company name. So that leaves your options pretty limited if you want go into any kind of detail.
  9. Cool stuff man! Awesome to see more game devs doing GDC talks (partly) on Houdini this year
  10. a way to group it with less nodes and without splitting it after the polycap is by grouping by range: so tube1 -> polycap_AddsMoreFaces -> Group_by_range: in the group by range, make the range: nprims("../tube") to $N it basically uses the heuristic that the primitive numbers of the polyCap always go after the input geometry.
  11. this is just single floating point accuracy, which is generally accepted to be 6 digits I think. even though Houdini floats are really 32 bit by default (in wrangles), which can represent more digits accurately, I guess its just the same baseline that is chosen.
  12. you can try adding an "up" vector attribute facing towards or away from the camera angle (90 degrees from the normal direction)
  13. vex

    well that is basically what (one of) petz's method(s) was doing, but the more often you have to search the array, the slower it will be. In my method, I do prevent putting the processed point itself in the array, but that's it.
  14. vex

    I found another vex method, about 10-15% faster than geo2/attribwrangle4 in your file: int collect[], prims[], points[], i, collectSort[], collectFin[]; prims = pointprims(0, @ptnum); foreach(int prim; prims) { points = primpoints(0, prim); for( i = 0; i < len(points); i++) { if(points[i] != @ptnum) append(collect, points[i]); } } collectSort = argsort(collect); for(i = 0; i< len(collect) ; i++) { if(i == 0 || collect[ collectSort[i]] != collect[ collectSort[i-1]]) append(collectFin, collect[ collectSort[i] ]); } i[]@collect = collectFin; it does output the array in a slightly different order though, and I'm not sure if it will work the same way with a string array, but its an idea
  15. If you have shape that is not aligned with the XZ plane, you could use the custom up vector, but then it does become important in which direction the curve is drawn. Or maybe I just put the cross product arguments in the wrong order. About the difference with the polyextrude... I have no idea