Thursday, May 26, 2011

Day 54

Today, I continued working on the rocks layer interaction.


However, I encountered a collision issue with the terrain. The arc that broke apart doesn't collide with the terrain. It just goes through it.

Below is how it looks,



The video,



I tried all kinds of method, I also did a test using a sphere, it worked through.

Below is how it looks,


Out of a sudden, I do not know what did I do and suddenly it worked. But the pieces are behaving quite crazily.




I then proceed on trying to delete the sphere after the dopnetwork. There seem to be an issue if I'm gonna do it procedurally. The issue is because, the groups get all totally renamed into something else. And the problem is I do not know which is the group that is the sphere.


Mr Michael suggested doing it the manual way, which is just drag over the sphere and delete in the viewport. It somehow worked.

Before:



 After:



I did a simulation to check if it collides and it seems like it does. I then happily went and did a rop.


 Little did I know that there is a huge problem awaiting me....

I then did a playblast of the result. This is what I get:


As you can see, there are a couple of serious issues that needs to be dealt with.

1) The erratic behaviour of the arc pieces colliding.
2) The spheres which appears at the back for no particular reason.

I consulted Jia bao on problem 2 first, he told me that I needed to turn off the display flag of the sphere before I do my rop. But the thing is I did my sphere, dops inside the geometry level, which doesn't have the display flag for it.

He helped me try to put a ends node at the end of the sphere and hopefully it will be seen as wireframe and it will not render out as a object. But unfortunately it didn't worked. He pointed to me Peter Quint's fracturing file as a reference. I will not dive into the scene but it should look familiar,




After browsing through, I decided to redo my entire dops in the scene level. I did it in a entire new file, hopefully it will help make things work and speed up the whole scene.


I somehow manage to delete the sphere using the procedural way. But however, I have problems with the collisions.


Below are some test simulations which are screwed.



I also realised that all rocks even arcs present in the scene have to have a initial gravity acting on it and they had to be all dynamic objects, if not when the pieces are falling, the rocks will float in mid-air. That proved to be a major issue as all the rocks and arc are interpenetrating the terrain, which makes converting them into dynamic objects harder.


It is 4am in the morning now. And until now, I haven't even had a single problem solved. I decided to do one last test and if it still doesn't work, I will scrape the entire idea of the rocks and arc on the terrain.

The last test:



Okay, so officially it doesn't work. Screw it man!

So now, I will scrape the entire idea like promised. I then went over and rop out the terrain simulations with the falling pieces with a color node and a vertex node to clean the fracture lines.

After that, I went into Jia Bao's lighting file and update the new files inside and did a test render. At first, it didn't show anything but after some debugging, It worked.


At 4.45am, I officially put it to render. I then went to sleep. God knows when it will finish rendering.




Back tracking now!


Earlier in the day, I encountered a up-resing issue for my terrain. At that point of time, Mr TK and Mr Michael was around and I brought up the problem to them. Mr TK suggested upresing the paint node and then using another paint node to show the up-resed paint data.

It worked! I double confirmed with Mr Ron regarding that up-resing method, and he said it will work.

Unfortunately, I will not be using this method for the final video on Friday.

Before:




















After:

Monday, May 23, 2011

Day 53

Today, I went on to add the arc and rocks and stuffs into the scene. Today, I came in and checked that my ropping of the bgeos sequences after the dopnetwork were done. Luckily. Initially, I started on the particles for the pieces falling down. I used a dopimport node to get the velocity attribute out from the dopnetwork. I then group points according to the velocity attribute in Y direction.





















The group node:




















I tried running it into the popnetwork immediately after this node, but it is INSANELY  slow. So I decided to rop it out. And the rop took me until Mr Ron came by for a review, which is almost 3 hours later and it is not even half way there. As Mr Ron was here, I canceled the ropping. I asked Mr Ron regarding about overlaying another simulation over the existing. He told me it was very easy, just bring in the other geometry pieces as static objects and make them fall inside dops.


He helped me optimised a terrain proxy to calculate the collisions of the extra geometries. He also helped me did a little demo on how to go about doing it. After that, I told him, I will give it a try regarding overlaying the simulations.


First, I rop out separate bgeos for the different rocks.




















I then imported them separately into the scene.

Inside the scene, I decided which rock I want it to break apart, and I did a fracturing system for each of them separately.

I picked the arc first,





















I will not go into the minor details, as this has been taught to me way back. Anyways, what is going on here in this hierarchy is, basically I am painting the pieces size on the geometry itself.




















After this, I used a sphere to break it all apart inside dops.




















Inside the dops, I imported the arc as a rbdfractureobject, and the sphere as a rbdobject. I then did a simple system after that and the result is that it breaks. I could also tweak the timing of the breaking, just by tweaking the sphere timing. I then hid the sphere. I then did a dopimport to bring the simulation out from the dopnetwork.

This is how it looks:



I then decided to do the breaking for another rock. I used exactly the same network to tackle this problem and the result is shown below:


I left the grouping of points based on velocity data bgeos sequence to rop overnight. Hopefully nothing will be wrong with it tomorrow.

Saturday, May 21, 2011

Day 52

Today, I started doing the dust emission from the terrain cracking. I emit particles at the edges of both terrain and add a gravity node for it to fall down. The color is also tweaked to the same as the terrain itself. As the earlier method to select the points procedurally didn't really work out, I went and selected the points individually. I then group them together and emit points based on that group. I also did a render of the entire terrain sequence.


I then did a render of the dust in a separate layer but when I tried to composite it, The position were totally off. I haven't got a chance to figure that out.

I spend the day ropping out the remainder of the dynamics bgeos sequences.

Thursday, May 19, 2011

Day 50

Mr Douglas dropped by today to check on our progress. I showed him the bgeo sequence I playblasted, with the pieces falling. He said it looks alright. The delayed load shader also works well for the render.

 

I heard some comments regarding the fracturing and I decided to fix them one by one.

1: The opening of the earth seems too wide.
2: The falling pieces are too big.
3: The terrain thickness should be much more.

For 1st comment, I went into the point node and tweak the multiplier lower,



For 2nd comment, I went into the crackmap and painted more on the edges and increase the scatter points to make the pieces smaller.


For the 3rd comment. I increased the extrudevolume node a lot more, to cover up the thickness of the terrain. 

I spend the day re-ropping out all the bgeo sequences.

Wednesday, May 18, 2011

Day 49

I started doing the cracking on the commercial version of Houdini using the new method Mr Ron told me about on Monday. I re-created everything the same way. I fused the points before the merge node. After doing that,  I re-create the groups using the new naming convention. Then I did the animated box coloring the terrain. I then pass it through another foreach to do the attribute promote. From here onwards, It became much slower. Hopefully, it will work though.

Tuesday, May 17, 2011

Day 48

Today, I continued doing what I am supposed to do. Below is the playblast of the cracking only:



While, I was still working on it, Mr Ron dropped by in the late morning, he told me he had an awesome idea, that will put all the research I did for the past 1 month plus to waste.

First, he created a foreach node after the point node to fuse up the points for each piece of the pre-fractured geometry.




















It is repeated for both sides. Then a merge node is used. After that the groups are cleaned up and renamed to a matching naming convention for both left and right piece.




















The clean node removes all the existing groups, connectivity creates a new attribute and connects the similar data type together. Partition node creates a new group based on the new attribute created earlier. Then after making sure the groups and primitive numbers are correct, We proceed on.

Before that, Mr Ron told me that, previously I used the facet node to clean up the pre-fractured pieces, which does the job, but that in turns increased the number of points which is not desired. Mr Ron told me that there is another node that I could use which does the same job but does not increase point numbers is the vertex node.




















Under the vertex node, the last option is switched on to "Cusp Normal" and there is a slider for tweaking. However, due to some display issues, the sliders needs to be reset first before it will work. The way to reset it is to drag it to 0 first before dragging it on to the value desired.

However, there will be some black "stuff " on the object itself after using the node, but it is alright, just some display issues. The render looks perfectly fine.


This is how the display looks:






















And the render:


(It is super low resolution, but you know what I mean though)


Mr Ron then told me what will happen next, which will blow my mind away, before he proceeds on. He told me that instead of using all the vopsop, copy loop and stuffs. He said that instancing would be a much better option.

How it will go about is that, the low resolution terrain will be used for the dynamic simulation, then from the dopnetwork, he will export out the data as points. Then he will instance the high resolution pieces onto the points and it can be rendered from there. This way, the whole simulation will be so so fast and the render fast too.

Firstly, since the initial simulation was done, he brought the whole thing into dops. As this was a test for proof of concept, Mr Ron just created a random fit expression for the velocity option under the rbdfracturedobject. This is how it looks with that expression alone:



Then a rbdsolver is used followed by a gravity node. Then after that, a dopimport node is used to import back the fracturing data as points data.




















It looks like this in the viewport:




















After that, We proceeded on to create the high resolution pieces that will be used for instancing. After changing the resolution of the terrain above, Everything else is the same thing. Until after the merge node,
A null is used to lock the position of the terrain, to not let it move.




















Then a delete node is used to delete everything but a piece of the pre-fractured geometry. A expression is used to allow the delete node to change the piece of geometry it keeps per frame. That will result in a animation of pieces of pre-fractured geometry moving around.

Below is how it looks:




















And how it look when it plays:




After that we ropped out the bgeo sequence of that. Then Mr Ron created a instance node on the scene level. Inside, a dopimport node is used to import the point data from the dop network. Then a material node is used. What it does is assign the shader to the terrain itself. But actually, a delay load shader is needed in this case. The "file" parameter from the delayed load shader is extracted out, and the bgeo sequence of each piece is assigned to it.




















The expression used in this case is $HIP/high/high.$ID.bgeo

It looks like a simple root file, but what the $ID does is shown below:




















The number at the end of the dopobject is the same as the id number of each piece. Hence $ID is used to represent the instanced dopobject for each piece.

The overall result is shown below:



Although it is quite difficult to see here, but it works. And I didn't even need to turn on the geo1 node which contains everything.

Sunday, May 15, 2011

Day 47

Today I went commercial for my cracking. I spend the day to redo my entire file in the commercial version. I requested for jia bao file, which contains the texturing and lighting. I was surprised as his scene has so many nodes. And I needed to rop out everything in a single node. I consulted Mr Ron regarding that, he tried converting all the lights in the scene into an otl at first, but it failed because the lights has references from elsewhere. Lastly, he introduced bundle to me. How it works is, it is something like a group and you can put everything inside a group, but the cool thing is, the group can be referenced anywhere.

After setting up all the bundles for the terrain, lights, rocks, etc. He created a new geometry container, and created a object merge node. He then brought in all the bundles and he asked me to rop it all out.

I decided to rop out the entire sequence first, then copy the shader over to the new file. However, after ropping out, I copied the shader over, and tried to render it, there seems to be a problem. I keep getting black screen in the render. Not knowing why, I consulted jia bao. At last, he fixed it for me, by removing the material under the geometry container. It somehow works though. He also told me that the arc and rocks positions weren't finalized yet. So I thought it would be safer to do it on the original terrain first. I managed to finish the cracking today though.


Cracking:

At first I managed to create the crack nicely. However, it is opening up in the wrong direction.


Not knowing why, I tried many variations but to no avail. I consulted Mr Michael, who was around at the moment. After much reasoning from him, he managed to get it to work. It was just playing around with the expressions.

Below is the expression which opens the crack the wrong way:



And the right way:




I will continue working on the file on Monday.