Author: digm520admin
//Youtube – Copy Object to Primitive Center
This simple tutorial is another way to project copies of objects onto the surface of another object. I came across this working on a separate part of my Houdini project, but this will come in handy very soon so I just wanted to document it.
//Vimeo – Intro to Procedural Modeling in Houdini: Making a Fence Asset
Notes: Projecting Curve down onto surface – make sure curve is entirely above surface first – done by transforming this up in y an amount equal to the bounding box of the terrain – can use Ray node – used wrangle – VEXpression to project curve onto terrain: vector rayd = {0, -100, 0}; vector hitP, hitUVW; int hitPrim = intersect(1, @P, rayd, hitP, hitUVW); @P = hitP; – this has every point fire a ray downward and determines where this ray intersects the terrain, and then sets that point’s position to the intersection point Create Orthos – used a Polyframe node – turned off the Normal Name and reassigned the Tangent Name to “N” – this made all the point normals basically follow allong the curve – use VEXpression to direct normal vectors – used wrangle: – VEXpression: vector up = {0, 1, 0}; v@side = normalize(cross(up, @N)); v@up = normalize(cross(@N, v@side)); – Seeing as this did two cross products in a row, I this sets v@side directly perpendicular to the curve (in plane) then v@up creates a vector perpendicular to all of this, including the plane (so this creates a vector that is up from the line) Created the Posts – simple boxes where we polyextruded the top with a bit of an inset Copy Posts to Terrain – Used simple copyToPoints with our post and points along the terrain – this placed their centers at the curve location however, so they were buried half way underground – to fix this, we added another attribute wrangle before the copyToPoints where we moved the points along their v@up vector a distance equal to half of an offsetDistance – the offsetDistance channel then referenced the box sizey so it was always half of the height of the box – this positioned the posts directly onto the surface Starting Fence Links Simple Spread – Made 3 new copies of our offsetDistance wrangle node – the general offset to center the posts went into the first copy – this copy offset was used for the link locations – this copy then went into both of the remaining offset copies – one of these final offset copies had an inverse relative reference to the other’s offset – these were merged – this merge with the combined offsets created a spread, where changing the offset of the one offset corresponded to a reverse offset of the other Creating Separate Staggered Lines – put all of the points of the link lines into a group called cut – used polycut node to turn all of these small line segments between the points into individual prims – used an attribute wrangle with modulus 2 function to basically remove every other primitive – we then used a copy of this setup but with the opposite modulus (when equal to 1 instead of 0) to delete the opposite segments – these were then combined with an offset to give an overall controllable pair of segment groups – this entire setup was then copied to create a second set of links all together Parameterization – Using the offset attribute wrangle we created in several different locations lets us control several dimensions of the fence links – overall distance of links from the ground – distance between the two sets of links – spread distance within a link set itself Creating Links – used a small grid as the base object – used Sweep node to place these all along the link points – used a Polyfill (the polycap they used must be deprecated) to fill in the ends of the links Extra Polish – to make the fence links feel less identical, they added a varied horizontal offset to them – this was done by using another copy of the offset wrangle created, but changing the v@up to v@side – they then added a dir (direction) vector, which used another mod 2 function, but fit the result between -1 and 1 – this was also applied to the offset, so the links would alternate offset directions with each link
//Vimeo – Intro to Procedural Modeling in Houdini: Making a Fence Asset
SideFX – Introduction to Procedural Modeling
Since my main issues for my procedural modeling project stem from not being familiar with procedural asset tools, I figured I should finally take that approach for my tutorial searches to help learn some new techniques. This led me to this great tutorial on creating a simple fence asset that I think will actually give me some pretty relateable tools when it comes to positioning parts for my frog generator. I am really hoping this helps me control the digits and toes of the frogs in a much nicer way.
The other link is actually a series of small tutorials. I wanted to grab these as well since they cover the basics again, which is something I can still use review on as often as possible, as well as leading into the creation of a procedural stair asset. This seems fairly simple, which is a nice way to start looking into how procedural assets are designed.
//Vimeo – Demonstration of the FollowFormation Scripts with Noise Features
This clip just shows off the different aspects and functionalities for my FollowFormation scripts so far.
I was working on a system in Unity for a class project that would allow a player to collect objects around the map by running into them, and then they would follow the player around in some sort of formation. This ended up working better by splitting the concept up into two classes: Leader (on the player object) and Follow (on the following objects).
Since we wanted to control the general formation of these objects as well, we’ll start with the Leader script. To make a simple and easily modifiable system, we decided on making a system based on a bunch of transforms childed to the player that would serve as the formation locations. The Leader script basically just grabs all of the children objects and holds them in an array. This is the formationPositions array. It then has a public static method that gives one of these gameObjects and then increments a counter so the next time it is called it returns the next one. This leads into the Follow script.
The Follow script is placed on the objects that will follow the player when collected. The first action is having them be collected in the first place. This is done with a simple collision that starts the following (and turns off the collider so they don’t interact with anything, including the player again). To help with the overall idea of being in formation, the Follow object actually grabs that next gameObject in the formationPositions array to follow around. This is how each object actually gets a different spot in the formation to follow around. With this setup, we just needed to determine how we wanted them to follow.
First, I tried using a combination of LookAt and adding a velocity in the transform.forward direction. This was solid for giving them a bit of an organic movement feel, but it was not very controlled. If the speed was very different from that of the player, their movements felt awkward and they would also tend to clump up. This could be an interesting solution route, but it would take a lot more work to function properly.
Next, we looked at simply setting the transform.position to the follow object. This wasn’t great as it looked very mechanical, especially immediately upon collecting the object. It would just teleport behind the player.
Finally, we settled on using a Lerp function along with the transform.position. With use of an additional speed variable, this gave us a nice, smooth motion that was easy to modify to give various feels.
After settling on the foundational movement for the following objects, we wanted to look into adding some noise to their movements to make them feel a bit more lifelike. Since I knew there were going to be a few different options of noise I’d like to switch between to see which ones felt better/worse with different parameters, I looked into setting up an enumerator with a switch case statement to easily switch between these different options. I simply created an enum called Motion that held a value for each of the different types of noise I made, and had a switch case check the Motion motion to determine which noise that specific object would use. This ended up being extra nice as I could also have different objects testing different types all at once.
It should also be noted that in order to keep things simple, I added the FormationNoise script directly to the formation position gameObjects that were childed to the player. Moving these simple transform objects would in turn move the following object following it as it is specifically given this gameObject transform to follow.
Finally, since everything was dealing with keeping these objects in the general area designated for their spot in a formation, the initialLocation is recorded on Start so we know its initial localPosition. This helped move the objects around this point, as opposed to continually adding or something and having it fly out of position.
The first noise we tried was a simple random range applied to the entire position vector of this formation position object. I created a variable for the max and min of the random range to randomly sift through, and every frame a value in this range would be added to the initialLocation. This actually ended up being pretty nice for creating a “buzzing” or “vibrating” effect, which was nice since these would eventually be applied to bee characters for the ‘ project, but other than that it was not very interesting motion.
Since that method seemed a bit too hectic, I wanted to test just adding some noise to a single dimension. I chose the x-axis to randomize along since that seemed like it would give the most interesting results from my camera top view. This did seem a bit more controlled, but still mostly just had a “buzzing” feel to it.
Finally, I thought about what general motion I would like along with the noise and I thought a nice overall controlled swaying and/or bobbing would be nice to have with the noise. This method got a bit more involved. I created a sway variable, which would determine the amplitude they would drift on a given axis (for initial testing, I just did the x-axis). I also created a swaySpeed to determine just how fast they moved between the max and min sway locations.
Since I liked the “buzzing” feel of random moving the point around a small range, I kept that for the y-axis and z-axis. I just had the sway controlling the x-axis movement. This had the object buzz around a bit as it moved back and forth relative to its given initial formation position. This all led to a nice movement that was still very controlled, but felt a lot more alive.
The movement of the objects when they are following a significantly fast player still looks pretty direct and parented. It appears that if their overall speed is much greater than the movements/speed of their internal noise methods, the noise gets a bit lost or drowned out. This is something I will just have to player with more when dealing with the relative speed of the following objects and the player.
Possibly control more axes of noise a bit more. Adding a bobbing effect by swaying in the y-axis would give a nice effect. If we control too many axes, we’ll have to recheck if it’s still a nice effect or if we’ll need to add more actual noise to the movements again to keep them from feeling too robotic.
Currently the setup of the Leader’s formationPositions array only makes an array the size of how many children the player object has at startup. This makes the system a bit rigid, or require having a bunch of unneccessary children objects for a while with possible errors for large numbers of followers exceeding the array count. A more variable system might use a list instead of an array, or just a large array with some method that creates gameObjects as followers are gained to add to that array.
//Youtube – Houdini add node tutorial (RUS)
Youtube – Houdini Training – Appendix 01 – basic SOPs overview
Youtube – Houdini Tutorial – SOP loops
My procedural modeling class recommended looking into the “Add” SOP to get some webbing for my frog feet generator, and searching for this also led me to some interesting basic overviews concerning SOPs in general in Houdini. Although I don’t speak Russian, the first quick video still makes sense with what is happening visually. The other videos are just really nice overviews for a lot of different SOP options available, which are going to be key for me to have a good understanding of for my frog generator.
//Pixel art is one of my go-to’s when I want to do a bit of 2D art for game projects I’m working on, so this video I came across seemed helpful.
This tutorial outlines a few common mistakes people make when doing simple pixel art and how to touch them up to make them look a lot nicer. A lot of it is focused on issues when making curves that either lead to weird patterns or inconsistencies. The end goes over proper outlining for sprites and how to use your outlines to emphasize certain features, like points/sharp ends.
//Youtube – MY NEW FAVOURITE FEATURE! – Shader Graph Tutorial
Youtube – FORCE FIELD in Unity – SHADER GRAPH
These tutorials get into the basics of using the Shader Graph feature in Unity. This seems like a nice tool to have a basic understanding of to make some cool effects, so I want to check in on it at some point.
//Youtube – Piranhaconda – Houdini SOPs Muscle and Wrinkles Tutorial
Vimeo – Houdini 16 Masterclass | Custom Shading
I am looking at creating a frog generating tool with Houdini as my final project for a procedural modeling class, so I just gathered a few tutorials that I thought might be helpful. The skin of the frogs is going to be a key feature that I don’t have much experience with, so I want to look into noise and shaders and how those go together to apply there.
The first video just seems like a generally helpful video for creatures, especially those without fur since the wrinkles should be much more noticeable. Frogs will also have some very visibly wrinkly locations dealing with their legs and face especially I think.
//– Can modify button actions real time and they will adjust (press, hold, toggle)– For Connections:     - Syntax         - [GameObjectName : ScriptName]         - InputType : NameOfInput     - InputType is either Input or Output     - Clumped GameObjectName and ScriptName means that script is attached as a component to that gameObject– NG = NodeGraph– Node outputs of “value”     - generally means it’s measuring some amount of something (usually normalized 0 – 1)         - i.e. SignalAngularVelocity has an output of “value”, which is a normalized measure of the amount of angular velocity the object currently has (currentVelocity / targetVelocity)
– SignalUnityEvent     - Call for something to happen, generally in another gameObject     - Usually found at the end of Node Graphs         - because they take other actions in as inputs to determine when to do an event– SignalMathCompare     - Has 2 inputs: in1, in2     - Output is 1 if both inputs are equal (the same); Output 0 otherwise     - also has an invertedOutput which is just the opposite out Output         - 1 when Output is 0         - 0 when Output is 1
– The Node Graph script itself creates entire Node Graph “shell”     - This creates two nodes within itself:         - Input Node: Only holds number of elements in the Inputs array Size         - Output Node: Only holds number of elements in the Outputs array Size     - At the higher level, it has both the inputs and outputs on its single node– Other scripts can creates nodes within the Node Graph, but they will generally create a single node     - This is different from the Node Graph script, which creates two nodes     - These nodes hold their inputs and outputs in the same node     - Examples:         - Button         - Net Signal– “Up” in the Node Graph will move to the Node Graph of the parent gameObject of the current Node Graph’s gameObject– A Node’s output generally goes to:     - another node script within the same gameObject     - node script within a gameObject that is a child of the current gameObject– Changing Node Graph connections may not update in real time     - It visually appears to be updating, but does not seem to actually take in change     - Need to stop playing, edit node connections, then start play again
– Start with an empty gameObject that just has a NodeGraph script     - NodeGraph can have 0 inputs and outputs– Create children gameObjects that will hold main NodeGraphs for this overall object     - The NodeGraphs for these objects cannot have 0 inputs AND 0 outputs     - They must contaion AT LEAST 1 input or output     - Adding an input or output to them will make the node appear in the overall NodeGraph in the parent object     - The internal NodeGraph (the NodeGraph of this specific child gameObject) will have separate input and output nodes         - It will remove the corresponding node if you specify 0 inputs or 0 outputs
//Youtube – [Unity] GPU Instancing Tutorial
In Unity, the benefits of GPU instancing may not be imediately noticeable by the FPS alone in the editor. This first tutorial shows that the FPS is more properly represented in an actual build of the project. Even though this is an older Unity version, that is still good to note to test all the way through to see if you are getting the expected results.
Following this tutorial appeared to work as intended, but it did have a weird issue where I couldn’t create lower numbers of instances of objects. Upon inspecting the script, I determined that any number below 1000 most likely would not be rendered out based on the for loop creating the batches at start. The following code snippet is where the issue was occurring: private void Start() { int batchIndexNum = 0; List
I would need to do further analysis to really understand the processing benefits of this, but it is a nice start to at least see that it is working and creating many instances of an object for me. I was safely able to create a few thousand instances of simple objects and run the game in the editor for what it’s worth. I also added a very basic 3D player controller that mostly moved the camera around to get a better idea of how everything was running with all of these objects created.