Jump to content

ColecloughGeorge

Members
  • Content count

    38
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

5 Neutral

About ColecloughGeorge

  • Rank
    Peon
  • Birthday 06/08/1999

Contact Methods

  • Website URL
    https://georgecoleclough.wixsite.com/3dvfx

Personal Information

  • Name
    George Coleclough
  • Location
    London

Recent Profile Visitors

124 profile views
  1. The correct way to handle collisions?

    Ahh ok thanks, I'll look into force calculations, but on the topic of vellum, I've had a look in the solver, and it uses position updates for external collisions too. They do: float C = dot(v@P - v@hitpos, v@hitnml); if (C < 0) v@P+= -C * v@hitnml; I'm just off to try that out, dunno why they use the letter C. Yeah it is for learning. Just got a bit sick of using these solvers as a black box. Thanks for the help and interest,
  2. The correct way to handle collisions?

    So currently, in the simplified scene, I'm grabbing the forces off of the force nodes, then I'm calculating the acceleration, velocity and position from those forces using: acceleration= (1 / f@mass) * force * Δt velocity= velocity0 + acceleration position= position0 + (Δt * velocity) after that I'm using the logic in the above diagram to handle the external collisions
  3. The correct way to handle collisions?

    This is occurring after the dynamics, I figured it was best to handle collisions last to ensure nothing intersects the next timestep. I've just found that it may be the case that the gas collision detect dop detects other particles in the same geometry, so I'm currently doing some testing on that
  4. xyzdist function check

    Yeah unfortunately you have to pass a geometry to xyzdist and to edit a geometry that isnt input 0 in a wrangle, you have to use sops. I think you can use python to edit two input geometries at once and it has a similar function geometry.nearestPrim() However I am unsure how to do this.
  5. xyzdist function check

    I initially tried to do this using the a group expression in the xyzdist, maybe you could still do that But this works. xyzdist.hipnc
  6. The correct way to handle collisions?

    Hi there while building the hip file, I implemented this solution This works somewhat, but particles fly everywhere, leak through colliders. When a surface collider is used, they just stick. The reason I am altering positions instead of velocities is because I am trying to emulate the position based approach here: https://vimeo.com/142534638#t=750s, but for external collisions. If this is a bad approach then I'll look into altering the velocity instead. Thanks pbdCollision.hipnc
  7. Houdini 18 Wishlist

    adaptive resolution flip solver https://www.youtube.com/watch?v=dH1s49-lrBk&t=0s style transfer upresing for smoke and possibly other effects I love cops but it often crashes, especially when viewing a live texture so some stability improvements would be great. For cops I would love to be able to write a kernel directly in houdini as opposed to the external function it seems to call currently. As an above post says, you may as well go full substance with cops Hom is great Cheers
  8. The correct way to handle collisions?

    Hi there. I am currently building a cloth solver and have just got onto external collision handling. For internal collision I am using the same pbd approach they show off in the grains masterclass. I thought I would go about external collisions a similar way, using a gas collision detect I get the incidence vector and reflect it. Then add the resulting reflected vector to the position. if (i@hitnum) { vector incidence= v@hitpos-v@P; float mag=length(incidence); vector reflection= reflect(normalize(incidence), normalize(v@hitnml)); v@P+=reflection*mag; } The cloth still blows up, even at a high substep Annoyingly a simple if (i@hitnum) v@P=v@hitpos; seems to work worlds better albeit the colliding points get stuck in place (which is something I aimed to fix by setting the new position to the reflected vector). The reason I'm not using the gas integrator to handle this for me is because I was looking to learn how this system is implemented. What is the correct way to go about this? As always any help is greatly appreciated Thanks
  9. Separate a building in two parts with a curve

    so it looks like you're comparing every point on the building to a point on the curve with a corrosponding point number. This won't work unless you put some work into somehow co-ordinating the point numbers beforehand. What I would do is look for the closest position on the curve geometry using: int prim=0; vector primuv={0,0,0}; xyzdist(1,v@P,prim,primuv); this will give you the closest prim and the position on that prim. then use: vector nearPos= primuv(1,"P",prim,primuv); to interpolate the point positions on the prim to that primuv location. then compare the current position with the nearestPosition: if(@P.x> nearPos[0]){ setpointgroup(0, "right_side", @ptnum, 1, "set"); } else{ setpointgroup(0, "left_side", @ptnum, 1, "set"); } This setup will only work in one plane, currently the x axis. To expand it and to prevent against looping curves you could look into using a cuttting plane and then analyzing the dot product of the nearest faces normal.
  10. Installing latest Nvidia drivers on Ubuntu

    I know it's different as I'm running debian but they are fairly similar. I get the drivers from the official repositories, in your case the ubuntu ones. For me there is just a package called nvidia-driver in synaptic which I download. That installs all the dependencies automatically, I then needed to get nvidia-opencl-common for opencl Also did you uninstall the open source nouveau drivers before installing the ppa? What does houdini log to the console as it crashed too? Good luck
  11. Quads instead of triangles

    It's not a simple issue, especially if you want quads for the sake of deformation or a subd workflow. Your best option is to use retopology tools. I'm used to quad draw in Maya but I believe houdini's tool is called topobuild, so I'd watch a few tutorials on that.
  12. Triggering a top cook from hda interface

    Scratch all that. It turns out I wasn't saving my hip file and pdg pulls from a hip and not the current session. Just stick a little dialogue box asking to save before you do your top cook.
  13. Particles into Grains ?

    Grains are just pops with a little added extra so you can source grains the same ways you would source pops. It doesn't matter the number of particles you just need a pscale attrib for grains to work.
  14. Solaris Reveal

    Fair points. I don't think I was considering big scale production as much as I'm currently a student. Backwards compatibility is always a concern as well. That said, I would still like to see obj become purely rigging in the future if it can't be integrated into lops, and modelling moved into lops as I think the ability to model in the layout context is quite intuitive. Also being able to easily use data from cameras and lights in your sop trees is useful. Didn't mean to come across ungrateful, this software is still leaps and bounds better than anything on the market.
  15. Triggering a top cook from hda interface

    Yeah, I thought so too but if you change the parameters on the hda, then use either dirtyTasks or dirtyAllTasks with or without the remove all argument, the graph will still not recognize the new paameter changes, This is also true of the pdg dirty functions. However this may be isolated to my file/machine/os so I would still say it's worth checking out
×