Today was the day of the final presentation. My presentation went quite well though, although I had to speed it up due to lack of time. Anyways, I will post my final shot and the breakdown later. Phew.
Thursday, August 25, 2011
Wednesday, August 24, 2011
Day 71
Today I came in and finished up tweaking my camera shake. I did a couple of test renders in Nuke to make sure they are alright before I set it off to render. I also rendered shot 2 out which hasn't had much compositing work to be done. After that I rendered and save out those passes that I wanted in my shot breakdown. I then went in to After Effects to do them. I finished my shot breakdown and I then went and compile all those screenshots and videos that I'm planning to show tomorrow.
After compiling them, I saved them in a folder and all I had left now is the PowerPoint slides which I will do at home.
Hope the presentation will go smoothly tomorrow!
After compiling them, I saved them in a folder and all I had left now is the PowerPoint slides which I will do at home.
Hope the presentation will go smoothly tomorrow!
Tuesday, August 23, 2011
Day 70
Today, I came in and continued archiving my hip file. Jeff Wagner had a class at 10am which was very interesting and useful.
After that, I did a little more archiving and it was off to Sony ImageWorks for the studio trip. Mr Ari drove us to the studio which was about a 10mins drive from SESI.
We were the first to arrive at the studio and we just hanged around there while waiting for the rest of the interns to arrive. We looked at their demo reel which was showing on a screen in the lobby.
The overall trip was a very enjoyable one, particularly because of him. We then headed back to SESI and continued working on our projects.
I managed to finish archiving my files completely. After that I moved on to compositing. I am still trying to fix the camera shake problem. Trying to blend between the static background at the back and the camera shake for the terrain in the front.
After that, I did a little more archiving and it was off to Sony ImageWorks for the studio trip. Mr Ari drove us to the studio which was about a 10mins drive from SESI.
We were the first to arrive at the studio and we just hanged around there while waiting for the rest of the interns to arrive. We looked at their demo reel which was showing on a screen in the lobby.
The overall trip was a very enjoyable one, particularly because of him. We then headed back to SESI and continued working on our projects.
I managed to finish archiving my files completely. After that I moved on to compositing. I am still trying to fix the camera shake problem. Trying to blend between the static background at the back and the camera shake for the terrain in the front.
Day 69
Today, when I came in my files are still rendering. And out of a sudden all my renders started crashing on the farm. The error log wasn't really that helpful also.
I then went into the render of my first shot. There were a couple of missing frames( like around 10plus) I went into my scene and re-render each of them individually. In the end, I managed to get it to finish and I have a complete sequence of shot one. Phew.
Now to shot 2, the renders on the farm screwed up quite bad. But luckily I foreseen a problem like this and as a backup, I rendered my entire shot 2 locally as well. The renders locally were perfect. Not a single missing frame. Next up, the dust. The dust was the most problematic of all. Initially when I rendered my dust, I brought it into Houdini COPS as a test frame. I realised that there wasn't enough dust and therefore I increased the particle birth rate. However, when I brought the render with more dust into Nuke, it looks totally screwed up.
It looks like this after I did an over with the terrain render.
The dust render with more dust:
The dust render with less dust:
God knows why is it like that. Hence, I went back to my first dust simulation file and re-started from there. I also tweaked a little of the lighting as it was too dark in the latest render. I realised that I couldn't use back the same lighting system that I used to light the terrain. I did some re-tweaking and I am good to go. The render with the less dust is the render which the lighting was also fixed.
I re-rendered the dust for both shots on the farm and it was super fast.
While I was at it, I started compositing in Nuke for the first time. I started compositing for the first shot. At first I had trouble separating the passes and stuffs like that but after consulting Zack about it, it became all clearer. I also managed to apply Zdepth to my render with Zack's help and also his help file. I also placed a background at the back of my render. I also added camera shake. Below is a single frame of how it looks,
Zack saw this render and told me that my background shouldn't be shaking too much as it is much much further away from the field of view. He also told me if I had time I should do some blending of the image with the terrain render.
I also started archiving my file.
I then went into the render of my first shot. There were a couple of missing frames( like around 10plus) I went into my scene and re-render each of them individually. In the end, I managed to get it to finish and I have a complete sequence of shot one. Phew.
Now to shot 2, the renders on the farm screwed up quite bad. But luckily I foreseen a problem like this and as a backup, I rendered my entire shot 2 locally as well. The renders locally were perfect. Not a single missing frame. Next up, the dust. The dust was the most problematic of all. Initially when I rendered my dust, I brought it into Houdini COPS as a test frame. I realised that there wasn't enough dust and therefore I increased the particle birth rate. However, when I brought the render with more dust into Nuke, it looks totally screwed up.
It looks like this after I did an over with the terrain render.
The dust render with more dust:
The dust render with less dust:
God knows why is it like that. Hence, I went back to my first dust simulation file and re-started from there. I also tweaked a little of the lighting as it was too dark in the latest render. I realised that I couldn't use back the same lighting system that I used to light the terrain. I did some re-tweaking and I am good to go. The render with the less dust is the render which the lighting was also fixed.
I re-rendered the dust for both shots on the farm and it was super fast.
While I was at it, I started compositing in Nuke for the first time. I started compositing for the first shot. At first I had trouble separating the passes and stuffs like that but after consulting Zack about it, it became all clearer. I also managed to apply Zdepth to my render with Zack's help and also his help file. I also placed a background at the back of my render. I also added camera shake. Below is a single frame of how it looks,
Zack saw this render and told me that my background shouldn't be shaking too much as it is much much further away from the field of view. He also told me if I had time I should do some blending of the image with the terrain render.
I also started archiving my file.
Friday, August 19, 2011
Day 66
Today, my cache files managed to finish over the night without failing. Lucky. I went ahead today with the re-tweaking of the lights. In the end, I decided on one look that I was satisfied with. I then proceed to throw the file into the render farm. I decided not to render a specular pass but instead render a Z-depth pass for the first shot. I asked Bryan on how to set it up.
I then moved on to the dust. I re-tweaked it a little more before I started rendering it. I then took a frame and compared it. The dust looks over-exposed.
I did a quick comp, and it looks quite bad. I then went back to my scene and started re-tweaking the lights. After much tweaking, I switched off the front and side light, keeping the spotlight and the point light on. Just keeping the spotlight on makes the dust looks quite dark.
After I did a render, I did a quick comp and the result was much better than before. I asked Tanner whether it looked okay. He told me the dust ring should be much bigger, the pieces that just started to crack should have dust.
I then went to do some tweaking. Initially, I was tweaking the velocity attribute in the source pop. The result is more like a cheat, as it translates the whole simulation. It looked like I could just get away with it in the beginning. But nearing the end, it started breaking apart.
I then decide to re-make the group that emits the particles. In SOPS, I did a group node that groups the points over time, and I made that group slightly bigger than the group that groups the points for fracturing. I then made a inner ring group that de-selects the points. I then subtracted the inner ring group from the main group. The result? I get a group ring that I could emit particles from.
I then used that group as the source group instead. I then also played with the impulse birth rate and the constant birth rate. I decide to put a much higher value on the impulse birth rate. I then increased the size of the initial size of the sprite. The end result was decent I would say. I then threw in the files to render locally.
Looking at the render farm, I decided to set up one of the renders just in case it couldn't finish over the weekend.
I then moved on to the dust. I re-tweaked it a little more before I started rendering it. I then took a frame and compared it. The dust looks over-exposed.
I did a quick comp, and it looks quite bad. I then went back to my scene and started re-tweaking the lights. After much tweaking, I switched off the front and side light, keeping the spotlight and the point light on. Just keeping the spotlight on makes the dust looks quite dark.
After I did a render, I did a quick comp and the result was much better than before. I asked Tanner whether it looked okay. He told me the dust ring should be much bigger, the pieces that just started to crack should have dust.
I then went to do some tweaking. Initially, I was tweaking the velocity attribute in the source pop. The result is more like a cheat, as it translates the whole simulation. It looked like I could just get away with it in the beginning. But nearing the end, it started breaking apart.
I then decide to re-make the group that emits the particles. In SOPS, I did a group node that groups the points over time, and I made that group slightly bigger than the group that groups the points for fracturing. I then made a inner ring group that de-selects the points. I then subtracted the inner ring group from the main group. The result? I get a group ring that I could emit particles from.
I then used that group as the source group instead. I then also played with the impulse birth rate and the constant birth rate. I decide to put a much higher value on the impulse birth rate. I then increased the size of the initial size of the sprite. The end result was decent I would say. I then threw in the files to render locally.
Looking at the render farm, I decided to set up one of the renders just in case it couldn't finish over the weekend.
Day 65
I set up my dust to render.My files on the farm also started moving. But they are crawling. There was a class scheduled today at 12pm to 1.30pm. So I didn't really start doing much work before I had to evacuate my work station to make way for the class. The class today was an introductory class to Houdini.
After the class, I then continued with my work. I took a frame of my dust and did a quick composition with the terrain and realised that there wasn't enough dust. I then started tweaking the dust.
Mr Steven dropped by in the evening to check on our progress. I showed him my terrain render and the dust, and also the quick composition. I told him that my files are taking very long to render. I was wondering if he could take a look at it and if possible help me optimise.
He took a look and first thing he told me was to turn off geometry velocity blur on my terrain. Then he reset my min/max ray samples to default and turn up my pixel samples to 5. He also told me not to use environment light as it will increase my render time by a decent amount. He also tried rendering out shadow maps. He also replaced my arealight to a spotlight with deep shadows.
He then asked me to send a frame of my cache file and my hip file to him so that he could take a even closer look. He also told me that I must cache the simulation files with a shader assigned out. He told me that I should find a way to fake the environment lighting without using the actual environment light.
I left the files to cache overnight.
After the class, I then continued with my work. I took a frame of my dust and did a quick composition with the terrain and realised that there wasn't enough dust. I then started tweaking the dust.
Mr Steven dropped by in the evening to check on our progress. I showed him my terrain render and the dust, and also the quick composition. I told him that my files are taking very long to render. I was wondering if he could take a look at it and if possible help me optimise.
He took a look and first thing he told me was to turn off geometry velocity blur on my terrain. Then he reset my min/max ray samples to default and turn up my pixel samples to 5. He also told me not to use environment light as it will increase my render time by a decent amount. He also tried rendering out shadow maps. He also replaced my arealight to a spotlight with deep shadows.
He then asked me to send a frame of my cache file and my hip file to him so that he could take a even closer look. He also told me that I must cache the simulation files with a shader assigned out. He told me that I should find a way to fake the environment lighting without using the actual environment light.
I left the files to cache overnight.
Wednesday, August 17, 2011
Day 64
Today, the dust render which I set up last night took so so long on a single computer. I guess that I had to use the render farm but till now, I still do not know why my files keep failing on the farm. Anyway, I tried tweaking the dust to optimise as much as I can. I made the size of the sprites smaller and also the particles birth rates. Hopefully it would speed things up.
I then asked Tanner if he happened to know why my files keep failing. He told me that everything that I submit onto the farm cannot have any spaces in them at all. God, my files all have spaces. I fixed them all up and threw it into the farm, and guess what? It worked perfectly.
I then moved on to my very troubling terrain. I passed Mr Steven the files that he requested from me. While I was waiting for his reply, I went ahead and did some render test for my passes. My plan was to have 3 passes, diffuse,specular and shadow. However, I couldn't get my passes to work. I then consulted Zack and he told me that as I was using a lighting model node at the end to color the shader. Lighting model node doesn't have the variables needed to rendered out the extra passes/image plane. He also told me that usually, surface model is used instead.
He then asked Charles to see if he knew something about it. Charles then helped me build both the specular and the diffuse from scratch, using a illumination loop. He made use of some complex mathematics and thinking.
It took him quite awhile before it got to somehow work. After that, I was thinking, why don't I just switch the lighting model node to a surface model node? It should work right?
After doing some test, I realised that it worked perfectly. Perfect.
Mr Steven then came back with a reply. He told me that he did a test on his own with my files and he didn't get the same problem which I had at all. But he advised me that for now, just get all the renders out first.
Anyway, just to make sure that my dust is working fine, I did a test render of the terrain at super low resolution and did a quick composite. Luckily the matte of the terrain which I rendered on the dust matched the terrain which I render.
I also set up the terrain render of both the cameras for the terrain.
I then asked Tanner if he happened to know why my files keep failing. He told me that everything that I submit onto the farm cannot have any spaces in them at all. God, my files all have spaces. I fixed them all up and threw it into the farm, and guess what? It worked perfectly.
I then moved on to my very troubling terrain. I passed Mr Steven the files that he requested from me. While I was waiting for his reply, I went ahead and did some render test for my passes. My plan was to have 3 passes, diffuse,specular and shadow. However, I couldn't get my passes to work. I then consulted Zack and he told me that as I was using a lighting model node at the end to color the shader. Lighting model node doesn't have the variables needed to rendered out the extra passes/image plane. He also told me that usually, surface model is used instead.
He then asked Charles to see if he knew something about it. Charles then helped me build both the specular and the diffuse from scratch, using a illumination loop. He made use of some complex mathematics and thinking.
It took him quite awhile before it got to somehow work. After that, I was thinking, why don't I just switch the lighting model node to a surface model node? It should work right?
After doing some test, I realised that it worked perfectly. Perfect.
Mr Steven then came back with a reply. He told me that he did a test on his own with my files and he didn't get the same problem which I had at all. But he advised me that for now, just get all the renders out first.
Anyway, just to make sure that my dust is working fine, I did a test render of the terrain at super low resolution and did a quick composite. Luckily the matte of the terrain which I rendered on the dust matched the terrain which I render.
I also set up the terrain render of both the cameras for the terrain.
Tuesday, August 16, 2011
Day 63
Today, I re-looked at the simulation. I tried to render a higher resolution image for Mr Steven and also tried to fix the removal of the pre-fractured lines on the terrain. I consulted Eric, Mr Ziggy and Charles about it.
Both Eric and Mr Ziggy advised me to render a matte for the fracture and render a un-fractured terrain separate. Mr Ziggy also mentioned to me that my terrain's voronoi fracture wasn't flat.
Hence even if I managed to clean out the lines, there will also be some black lines on the terrain itself also(due to the unevenness of the terrain).
Still not being able to solve my problem, I consulted Charles about it. He helped me by trying to transfer the new vertex attribute from the un-fracture terrain onto the fracture terrain. It looked okay in the viewport, but when I render there were still a couple of fracture lines still visible. I'm not sure if it still can be fixed though. I managed to spit out a higher resolution render:
But anyway, I went ahead and did a quick comp of the terrain with the dust. This was how it looked:
(Mind the pre-fractured lines)
Seeing that it looked quite okay, I went ahead with the render. Then I went back to my terrain. Still find that my terrain looks very ugly. Did a quick render of the terrain at higher resolution. Looks better. I do not know if I should take a gamble and try to up-res the simulation to mid-res or just stay at low-res. I took the gamble in the end, and the voronoi fracture has been cooking for the past 30mins. I wonder if that's a good sign.
Both Eric and Mr Ziggy advised me to render a matte for the fracture and render a un-fractured terrain separate. Mr Ziggy also mentioned to me that my terrain's voronoi fracture wasn't flat.
Hence even if I managed to clean out the lines, there will also be some black lines on the terrain itself also(due to the unevenness of the terrain).
Still not being able to solve my problem, I consulted Charles about it. He helped me by trying to transfer the new vertex attribute from the un-fracture terrain onto the fracture terrain. It looked okay in the viewport, but when I render there were still a couple of fracture lines still visible. I'm not sure if it still can be fixed though. I managed to spit out a higher resolution render:
But anyway, I went ahead and did a quick comp of the terrain with the dust. This was how it looked:
(Mind the pre-fractured lines)
Seeing that it looked quite okay, I went ahead with the render. Then I went back to my terrain. Still find that my terrain looks very ugly. Did a quick render of the terrain at higher resolution. Looks better. I do not know if I should take a gamble and try to up-res the simulation to mid-res or just stay at low-res. I took the gamble in the end, and the voronoi fracture has been cooking for the past 30mins. I wonder if that's a good sign.
Monday, August 15, 2011
Day 62
Today, I looked at the render that I set up over the weekend. It looked ugly. Anyway, I guess it wasn't the final one either. I started with the dust tweaking and render. For some reason it doesn't seem to render when I tried to render it. Finally, I realised that it is rendering just that it takes so long. I managed to get one frame out without motion blur.
Later on, I tried rendering it again but this time with motion blur, it took 2hours and it still isn't done yet. Hence, I cancelled it.
I then moved on to the terrain. I remembered that Mr Steven mentioned that distant light can't cast depth map shadows. Hence, I switched my light to an area light. Made the scene brighter, by increasing the environment light, and also adding global illumination. Helps a little. However, there were a couple of black artifacts in the render.
Not knowing why, I emailed Mr Steven. Mr Steven provided me a method that I could remove the artifacts and hopefully also the fractured lines.
The result?
The black artifacts looks like they disappeared. However, it left behind some pre-fractured lines.
Later on, I tried rendering it again but this time with motion blur, it took 2hours and it still isn't done yet. Hence, I cancelled it.
I then moved on to the terrain. I remembered that Mr Steven mentioned that distant light can't cast depth map shadows. Hence, I switched my light to an area light. Made the scene brighter, by increasing the environment light, and also adding global illumination. Helps a little. However, there were a couple of black artifacts in the render.
Not knowing why, I emailed Mr Steven. Mr Steven provided me a method that I could remove the artifacts and hopefully also the fractured lines.
The result?
The black artifacts looks like they disappeared. However, it left behind some pre-fractured lines.
Friday, August 12, 2011
Day 59
Today's the first day of work after the week-long Vegas trip. Still feeling the blues though. But anyway, today, I finalize the tweaking of the simulation and did a re-rop.
I then went on to the dust simulation and also the debris.
I still hadn't got a chance to view the previous render I set up before I left for Vegas. But will see it soon I hope. And I also applied the shader to the fractured terrain. It looked decent to me.
And the debris:
The dust render took a long long time, so I didn't wait for it to finish. I then set up a render of the entire terrain wit the shader over the weekend.
I then went on to the dust simulation and also the debris.
I still hadn't got a chance to view the previous render I set up before I left for Vegas. But will see it soon I hope. And I also applied the shader to the fractured terrain. It looked decent to me.
And the debris:
The dust render took a long long time, so I didn't wait for it to finish. I then set up a render of the entire terrain wit the shader over the weekend.
Day 52
Today, I came in as usual, I continue trying to fix the enormous amount of scatter points problem and to no avail. Mr Steven dropped me a email and described the problem I encountered in very thorough detail.
Firstly, I brought up to him the problem I faced while up-res ing the terrain. My fractured pieces sizes and position changed after I up-res them despite them being the same geometry and the same number of scatter points, except that the geometry is of higher resolution. Mr Steven then told me that the problem was because I was re-creating the scatter points again for the up-res terrain, hence it resulted in the difference.
He told me that scatter sop scatter point based on the area and size of the geometry. I should instead use the same scatter sop that was used for the low-res terrain on the high-res terrain.
Next, I brought up to him Mr Ari's idea, which is using the paint sop to paint the density of the scatter points. As I had previous experience with that, I knew that when I up-res the geometry, the paint map will be destroyed. Hence, I brought it up to him.
He told me that, I do not paint the paint map onto the geometry. I paint on a grid similar to the terrain and then use it to create the scatter points and then pass it into the fractured geometry.
I also brought up to him regarding my excessive long cooking time. He asked me if it was really necessary to use such high resolution geometry?
Later in the afternoon, he called to check on my progress. I told him I was sticking with the paint map method and it was working pretty well. And I also told him that I tried using the low-res geometry with my shader, it looked decent, but definitely not as nice as the high resolution one.
He then dropped by in the evening for our weekly progress. He said my simulation was working fine, except of a couple of issues. Such as spinning geometries after colliding, overlapping of the ripple effect.
He also taught me some ways to cheat. I just realised that there were plenty more to do. But anyways, looking on the bright side, tomorrow is Universal Studios! Followed by Las Vegas. Real good time to take a nice long break, but hopefully I will still be able to catch up after that.
Firstly, I brought up to him the problem I faced while up-res ing the terrain. My fractured pieces sizes and position changed after I up-res them despite them being the same geometry and the same number of scatter points, except that the geometry is of higher resolution. Mr Steven then told me that the problem was because I was re-creating the scatter points again for the up-res terrain, hence it resulted in the difference.
He told me that scatter sop scatter point based on the area and size of the geometry. I should instead use the same scatter sop that was used for the low-res terrain on the high-res terrain.
Next, I brought up to him Mr Ari's idea, which is using the paint sop to paint the density of the scatter points. As I had previous experience with that, I knew that when I up-res the geometry, the paint map will be destroyed. Hence, I brought it up to him.
He told me that, I do not paint the paint map onto the geometry. I paint on a grid similar to the terrain and then use it to create the scatter points and then pass it into the fractured geometry.
I also brought up to him regarding my excessive long cooking time. He asked me if it was really necessary to use such high resolution geometry?
Later in the afternoon, he called to check on my progress. I told him I was sticking with the paint map method and it was working pretty well. And I also told him that I tried using the low-res geometry with my shader, it looked decent, but definitely not as nice as the high resolution one.
He then dropped by in the evening for our weekly progress. He said my simulation was working fine, except of a couple of issues. Such as spinning geometries after colliding, overlapping of the ripple effect.
He also taught me some ways to cheat. I just realised that there were plenty more to do. But anyways, looking on the bright side, tomorrow is Universal Studios! Followed by Las Vegas. Real good time to take a nice long break, but hopefully I will still be able to catch up after that.
Thursday, August 4, 2011
Day 51
The cooking I set up yesterday before I left crashed when I came in today morning. I kind of expected it too though. Anyway, I re-set the entire simulation all over, but I scattered less points. It managed to survive finish voronoi fracture. Luckily. I'm at foreach now, and it has been cooking for 4hours plus at least. It's a miracle it didn't crash yet.
Mr Ari also came and looked at my progress for this week. He told me that my shader render looked washed out, as in there isn't any depth between the shadows and highlights. I also mentioned to him about the simulation issues I had. He gave me some suggestions though, but I had to consult Mr Steven first.
So, I ended up working on shaders and touched a little on instancing for the rocks. I managed to do a brief version of the instancing and I wonder how it will look, it still looks kind of uniform. I also had a shader test done. Now trying to put the shader and the instancing together to see how it looks.
Mr Ari also came and looked at my progress for this week. He told me that my shader render looked washed out, as in there isn't any depth between the shadows and highlights. I also mentioned to him about the simulation issues I had. He gave me some suggestions though, but I had to consult Mr Steven first.
So, I ended up working on shaders and touched a little on instancing for the rocks. I managed to do a brief version of the instancing and I wonder how it will look, it still looks kind of uniform. I also had a shader test done. Now trying to put the shader and the instancing together to see how it looks.
Wednesday, August 3, 2011
Day 50
The single render I set up yesterday before I left, It hasn't finished when I got here today morning. I wonder what is wrong. But anyway, this was how it looked:
The low res simulation looks decent. But while I was working on my up-res simulation I realised that something was really very very wrong.
Let's take an simple example of what my problem is,
Imagine a grid with 10 by 10 rows and columns. You put a bounding sphere in the center and delete everything else but the area that the bounding sphere is covering.
The result? A area that looks like a "+" And imagine that you pre-fracture that with N number of points.
Then if you increase the resolution of the rows and columns to maybe 100 by 100 and use exactly the same settings as before, you will get a shape very close to a circle. And imagine it is also pre-fracture with the same number of points.
Now if you compare both geometries. There is firstly, a very vast difference in shapes and also the size/position/scale of each fracture piece.
The conclusion? I am so screwed.
Re-doing, the low-res fracture and also the high res simulation within tomorrow hopefully.
But luckily my shader and lighting aren't screwed up yet....
The low res simulation looks decent. But while I was working on my up-res simulation I realised that something was really very very wrong.
Let's take an simple example of what my problem is,
Imagine a grid with 10 by 10 rows and columns. You put a bounding sphere in the center and delete everything else but the area that the bounding sphere is covering.
The result? A area that looks like a "+" And imagine that you pre-fracture that with N number of points.
Then if you increase the resolution of the rows and columns to maybe 100 by 100 and use exactly the same settings as before, you will get a shape very close to a circle. And imagine it is also pre-fracture with the same number of points.
Now if you compare both geometries. There is firstly, a very vast difference in shapes and also the size/position/scale of each fracture piece.
The conclusion? I am so screwed.
Re-doing, the low-res fracture and also the high res simulation within tomorrow hopefully.
But luckily my shader and lighting aren't screwed up yet....
Tuesday, August 2, 2011
Day 49
Today, I am still at the process of extracting a single bgeo file of the exact scatter points used. Having a real hard time doing that, due to houdini being so slow. I am at the last stage of it, at the foreach sop. And that foreach sop has been running for an hour plus and it is not even creating the point in the center of each piece yet.
God knows when it will finish. I'm only at estimated 25k scatter points and 50 by 50 for resolution.
Anyway, while I was at that, I went back to shaders. I consulted Charles and Mr Steven regarding the scaling problem I had with my shaders. Mr Steven told me that I should do my transform before my UVProject. So that my UVs are of the same scale as my terrain.
Before:
After:
I fixed the UVs and it still doesn't work. I consulted Charles regarding this problem. He told me that it's because the UV's are scaled in world space.
He did a multiplied the point position by a constant and then connects that into a rest position node.
He didn't change anything else, except connect all inputs into the rest position node.
Shader Network:
I didn't build this.
After that I did some simple test. I then send an update to Mr Steven. Mr Steven told me that looked okay and asked me to proceed.
I then decided to copy the nodes into my actual simulation file. (I was working on a test file)
After that, I decided to do a test render of the terrain at the exact resolution I was going to use. Will post them when they are done/available.
Some test renders of the terrain with the shader:
I rebuilt the file in commercial version and it looked different...But still decent I hope.
God knows when it will finish. I'm only at estimated 25k scatter points and 50 by 50 for resolution.
Anyway, while I was at that, I went back to shaders. I consulted Charles and Mr Steven regarding the scaling problem I had with my shaders. Mr Steven told me that I should do my transform before my UVProject. So that my UVs are of the same scale as my terrain.
Before:
After:
I fixed the UVs and it still doesn't work. I consulted Charles regarding this problem. He told me that it's because the UV's are scaled in world space.
He did a multiplied the point position by a constant and then connects that into a rest position node.
He didn't change anything else, except connect all inputs into the rest position node.
Shader Network:
I didn't build this.
After that I did some simple test. I then send an update to Mr Steven. Mr Steven told me that looked okay and asked me to proceed.
I then decided to copy the nodes into my actual simulation file. (I was working on a test file)
After that, I decided to do a test render of the terrain at the exact resolution I was going to use. Will post them when they are done/available.
Some test renders of the terrain with the shader:
I rebuilt the file in commercial version and it looked different...But still decent I hope.
Monday, August 1, 2011
Day 48
Today, I decided to set up the final amount of fractured pieces I'm going to use. I also decided to break the terrain up into 3 parts and fracture them separately. I went with 20 000 scatter points for the center piece, 15 000 scatter points for the middle piece and 18 000 scatter points for the outer piece. I then file out each individual portion and merged them together.
The merged file was 4GB. And there was no animation at all and it was just one single file. Anyway, I still need to re-form the groups for all the pieces and run through a foreach. God knows how long it will take..
Back to shader, Until now I still had the scaling problem of my shader, when I do not scale my terrain, my shader looks fine, if I scale it, it looks horrible. Still in the process of figuring out how to fix it. Hopefully soon....
The merged file was 4GB. And there was no animation at all and it was just one single file. Anyway, I still need to re-form the groups for all the pieces and run through a foreach. God knows how long it will take..
Back to shader, Until now I still had the scaling problem of my shader, when I do not scale my terrain, my shader looks fine, if I scale it, it looks horrible. Still in the process of figuring out how to fix it. Hopefully soon....
Friday, July 29, 2011
Day 44 & 45
DAY 44:
I continued working on the ripple effect in POPS. I thought it will be nearing completion. However a problem cropped up yesterday. The method which Mr Steven showed to me, regarding pre-fracturing the pieces and then in POPS, choose the emission type as Prim Center(Ordered) doesn't work. If I pre-fracture my terrain, there will be the pre-fracture lines and the grid-like lines as well.
And if I bring that into pops, POPS will get confused and the result is totally crazy.
I asked Charles for help and he tried projecting the crack lines on to a clean grid. It worked, but I will lose the terrain details.
Mr Steven told me to move on and try another method. I decided to use the method which originates from Mr Ron and it was further worked on and edited by the people on odforce.
http://forums.odforce.net/index.php?/topic/13709-copying-problem-weird-rotation/
What this does is, I pre-fracture the geometry, add a point in the center of each chunk, run the bunch of center points into POPS. There is also added angular velocity for rotation purposes.
Then the points, particles are copied on a VOPSOP. I also touched on shaders a little. And below is a simple render test.( Not the exact terrain scale )
DAY 45:
Today, I wanted to finish a low-res simulation to show Mr Steven. And I managed to did it. I spend the whole afternoon rebuilding the VOPSOP method. Then there was some crazy issues with the rebuilding of the VOPSOP. The pieces do not turn! And I did exactly the same thing. And there is angular velocity too.
Anyway, the problem was, it should be " instead of '. And I forgotten to connect a single attribute correctly. Anyway, the problem was fixed. I sent the playblast videos to Mr Steven and he said, the pieces seems to fall too fast, and the ripple is still very tight.
That's the end.
I continued working on the ripple effect in POPS. I thought it will be nearing completion. However a problem cropped up yesterday. The method which Mr Steven showed to me, regarding pre-fracturing the pieces and then in POPS, choose the emission type as Prim Center(Ordered) doesn't work. If I pre-fracture my terrain, there will be the pre-fracture lines and the grid-like lines as well.
And if I bring that into pops, POPS will get confused and the result is totally crazy.
I asked Charles for help and he tried projecting the crack lines on to a clean grid. It worked, but I will lose the terrain details.
Mr Steven told me to move on and try another method. I decided to use the method which originates from Mr Ron and it was further worked on and edited by the people on odforce.
http://forums.odforce.net/index.php?/topic/13709-copying-problem-weird-rotation/
What this does is, I pre-fracture the geometry, add a point in the center of each chunk, run the bunch of center points into POPS. There is also added angular velocity for rotation purposes.
Then the points, particles are copied on a VOPSOP. I also touched on shaders a little. And below is a simple render test.( Not the exact terrain scale )
DAY 45:
Today, I wanted to finish a low-res simulation to show Mr Steven. And I managed to did it. I spend the whole afternoon rebuilding the VOPSOP method. Then there was some crazy issues with the rebuilding of the VOPSOP. The pieces do not turn! And I did exactly the same thing. And there is angular velocity too.
Anyway, the problem was, it should be " instead of '. And I forgotten to connect a single attribute correctly. Anyway, the problem was fixed. I sent the playblast videos to Mr Steven and he said, the pieces seems to fall too fast, and the ripple is still very tight.
That's the end.
Wednesday, July 27, 2011
Day 43
Today I continued with the ripple effect. Mr Steven showed me 2 files which describes what I wanted, how do I copy the fracture pieces onto the particles network simulation?
First he showed me a system which uses copy stamping:
What this does is he uses an expression to delete the pieces and then uses copy stamping to copy it onto the points.
It somehow worked, but there was this weird rotation that was going on. I emailed Mr Steven again, asking him if he knew what the problem was.
He told me that the pieces were copied to the velocity vector hence they rotate in a weird way.
He then showed me another method which was very very very much simpler to understand, and simpler to do.
At first, I couldn't even believe that it could be done this way.
Anyway, it worked perfectly. Mr Steven then asked me to test out the simulation with a grid size similar to my terrain, to determine roughly how many scatter points is needed. I tried a grid with 500 rows and columns. The cache file for the simulation amounted to 16 GB. And the simulation became super low. Maybe that was the limit.
After that, I went ahead into using my actual terrain. I realised that, given the severe unevenness of the terrain, I had a lot of trouble trying to group the particles for the ripple to throw it back down. I tried many methods, I tried using a bounding object as the bounds for the grouping, but it didn't really work that well, some particles still seep through resulting in crazy, stretching pieces. I tried setting that object that I am using for the bound to a collision object, and the problem with that was the bounce was super sensitive. Resulting in the particles flying all over the place.
Hence, I decided that the easiest solution for me to fix it was to flatten my entire terrain. Get rid of the mountains and stuffs. I will do it tonight.
Anyway, I would like to thank Mr Steven for the amount of help and help files he provided me during this past few days.
I guess I got to finish quick, If not there will not be anything new to show him tomorrow.
And there was another method of copying that I posted on odforce because I would like to know how to do it.
http://forums.odforce.net/index.php?/topic/13709-copying-problem-weird-rotation/
And I also finally came up with a production schedule. And after doing it, I realised that I still have a lot more work to do. Got to pull my socks up though.
First he showed me a system which uses copy stamping:
What this does is he uses an expression to delete the pieces and then uses copy stamping to copy it onto the points.
It somehow worked, but there was this weird rotation that was going on. I emailed Mr Steven again, asking him if he knew what the problem was.
He told me that the pieces were copied to the velocity vector hence they rotate in a weird way.
He then showed me another method which was very very very much simpler to understand, and simpler to do.
At first, I couldn't even believe that it could be done this way.
Anyway, it worked perfectly. Mr Steven then asked me to test out the simulation with a grid size similar to my terrain, to determine roughly how many scatter points is needed. I tried a grid with 500 rows and columns. The cache file for the simulation amounted to 16 GB. And the simulation became super low. Maybe that was the limit.
After that, I went ahead into using my actual terrain. I realised that, given the severe unevenness of the terrain, I had a lot of trouble trying to group the particles for the ripple to throw it back down. I tried many methods, I tried using a bounding object as the bounds for the grouping, but it didn't really work that well, some particles still seep through resulting in crazy, stretching pieces. I tried setting that object that I am using for the bound to a collision object, and the problem with that was the bounce was super sensitive. Resulting in the particles flying all over the place.
Hence, I decided that the easiest solution for me to fix it was to flatten my entire terrain. Get rid of the mountains and stuffs. I will do it tonight.
Anyway, I would like to thank Mr Steven for the amount of help and help files he provided me during this past few days.
I guess I got to finish quick, If not there will not be anything new to show him tomorrow.
And there was another method of copying that I posted on odforce because I would like to know how to do it.
http://forums.odforce.net/index.php?/topic/13709-copying-problem-weird-rotation/
And I also finally came up with a production schedule. And after doing it, I realised that I still have a lot more work to do. Got to pull my socks up though.
Tuesday, July 26, 2011
Day 42
Today, Mr Steven provided his version of my file to me. I looked through it and the result looks much better than my own version. He edited my network, he created a random force for the ripple effect using a expression.
He increased the upward force and also the downward force, to create that "up down" effect.
This was how it looked:
Mr Steven also told me that I should increase the upward force and add rotation values to the pieces.
I managed to accomplish both tasks:
1: Increase upward force
To increase the height of the ripple, I played with both the upward force that throws it up and also the downward force that throws it down.
2: Add rotation values
I did a group of the pieces in mid-air in SOPS. I then applied a primitive sop to the group with a random rotation expression.
And it looks decent I would say,
Mr Steven also told me that I may need a deformed ground for collision and up till now I haven't got it to work. And also the pre-fracture technique.
He increased the upward force and also the downward force, to create that "up down" effect.
This was how it looked:
Mr Steven also told me that I should increase the upward force and add rotation values to the pieces.
I managed to accomplish both tasks:
1: Increase upward force
To increase the height of the ripple, I played with both the upward force that throws it up and also the downward force that throws it down.
2: Add rotation values
I did a group of the pieces in mid-air in SOPS. I then applied a primitive sop to the group with a random rotation expression.
And it looks decent I would say,
Mr Steven also told me that I may need a deformed ground for collision and up till now I haven't got it to work. And also the pre-fracture technique.
Monday, July 25, 2011
Day 41
Today, I feel that I accomplished quite a fair bit today. I managed to complete the ice pops tutorial without much problems. And I also managed to tweak the settings in pops to look like a ripple. Now all I left is knowing how to copy the pre-fracture pieces to each point.
I tried a couple of ways:
First, The ice pops tutorial way:
And this was the result:
It works though, but the geometry looks weird. Not knowing why, I moved on to another method.
Second, Mr Ron's vopsop copy method during FYP:
I tried Mr Ron's vopsop method that he taught me during FYPJ. This was the result:
And this doesn't work for some reason. Okay time to move on.
I went back to the first method. Thinking something is wrong, I went back inside pops and started playing around with the emission type.
I stumbled upon Prim Center(ordered) and realised that it works.
And this was how it looks after being copied:
And this was how it looks when I did a playback:
It kind of worked, so, I decided to start playing around with the settings on how it should react after it come back down to its original position.
At first I thought collision will be able to solve everything, hence I spend a long time tweaking it. I made it bounce first, then stop. Bla bla.. However, after that I realised that it will not work. First the bounciness is too difficult to control. Secondly, the direction of it bouncing is difficult to control also.
I decide to come out of pops, do a group of the points in mid-air and do a point jitter. I tried jittering them when they went back to their original positon and it looked weird. I also consulted Steven on a couple of issues. Like, what if I wanted to pre-fracture my geometry and this method may not even work out.
I ended like that.
I tried a couple of ways:
First, The ice pops tutorial way:
And this was the result:
It works though, but the geometry looks weird. Not knowing why, I moved on to another method.
Second, Mr Ron's vopsop copy method during FYP:
I tried Mr Ron's vopsop method that he taught me during FYPJ. This was the result:
And this doesn't work for some reason. Okay time to move on.
I went back to the first method. Thinking something is wrong, I went back inside pops and started playing around with the emission type.
I stumbled upon Prim Center(ordered) and realised that it works.
And this was how it looks after being copied:
And this was how it looks when I did a playback:
It kind of worked, so, I decided to start playing around with the settings on how it should react after it come back down to its original position.
At first I thought collision will be able to solve everything, hence I spend a long time tweaking it. I made it bounce first, then stop. Bla bla.. However, after that I realised that it will not work. First the bounciness is too difficult to control. Secondly, the direction of it bouncing is difficult to control also.
I decide to come out of pops, do a group of the points in mid-air and do a point jitter. I tried jittering them when they went back to their original positon and it looked weird. I also consulted Steven on a couple of issues. Like, what if I wanted to pre-fracture my geometry and this method may not even work out.
I ended like that.
Friday, July 22, 2011
Day 38
Okay, so I am officially behind time. Mr Steven came in today and told me that my dops simulation is still not there yet. I mentioned to him that my scene is getting so so heavy now that it crashes every now and then.
He told me that there were a couple of issues. My fractured pieces looks more like they are stretching rather than breaking. And I agree with him. He then told me that instead of running simulations, why don't I try it using pops. Like add a point in the center of each piece and then copy each piece to each point.
Luckily, I did something like that before during FYP. So maybe I would have a head start somehow.
He directed me to a pdf and told me to start looking at it.
I spend the whole day playblasting files and looking at houdini crashing.
He told me that there were a couple of issues. My fractured pieces looks more like they are stretching rather than breaking. And I agree with him. He then told me that instead of running simulations, why don't I try it using pops. Like add a point in the center of each piece and then copy each piece to each point.
Luckily, I did something like that before during FYP. So maybe I would have a head start somehow.
He directed me to a pdf and told me to start looking at it.
I spend the whole day playblasting files and looking at houdini crashing.
Thursday, July 21, 2011
Day 37
Today was a day where a lot of cooking occured. I re-tweaked my simulation until I am sort of happy today and we got news that Steven will be coming in tomorrow. I tweaked my simulation until I do not know what else can be tweaked.
But anyways, I decided to increase the scatter points for the simulation to test it out and also to let Steven look at it tomorrow so there is more variety.
I have a couple of playblast that I rendered, but they are all in wireframes.
That means that more ropping needs to be done. And the ropping takes so long. I will stick to the current simulation settings for now and see what Steven says tomorrow before I proceed further.
But anyways, I decided to increase the scatter points for the simulation to test it out and also to let Steven look at it tomorrow so there is more variety.
I have a couple of playblast that I rendered, but they are all in wireframes.
That means that more ropping needs to be done. And the ropping takes so long. I will stick to the current simulation settings for now and see what Steven says tomorrow before I proceed further.
Wednesday, July 20, 2011
Day 36
Today I continued with the ripple effect. I broke up my terrain as what Steven told me. And this was how it looked( after pre-fracturing it )
I started working in the center impact portion. And that portion also happens to have the most scattered points on it.
I re-did my entire system from before. And after doing it, I realised that after the ripple occured, my fractured pieces still continue to bounce.
Not knowing why, I consulted Eric for advice. He told me that the most logical reason he can think of is because I added a force to force the pieces up and I also added another force to force the pieces down. Hence, that results in the bouncing in mid-air effect.
He told me to try to work simple if I wanted to work with groups.
Hence, I sat down thought through how I wanted it to be.
And suddenly I realised, since I already defined color inside dops, why don't I use that group to force the pieces to go up and then add a gravity node and force the pieces down after that? It may sound the same, but the group which is created based on color takes in the pieces based on the color value. Which in this case is driven by the a torus-like shape which is animated against time. Hence, some pieces which are affected by the group will go out of the group once they lose their color values. Hence, I could have more control.
I proceed on in that direction. For the gravity force pushing the pieces down, I went with the same expression that groups the pieces based on their position data.
And I will post some test videos below.
Anyway, after making sure that looks decent, I proceeded on with the second layer of the terrain.
I realised that using the same settings for the smaller terrain portion will not work for the bigger one. More settings needed to be tweaked. Or maybe its because of the piece size. Who knows?
Anyways, I played with the glue value, put that to 0. I changed the rotational stiffness and the friction.
I also increased the force that pushes the pieces upwards and decrease the forces that pushes the pieces downwards. I just played with it and hopefully I could show Steven something decent if he comes in tomorrow.
I started working in the center impact portion. And that portion also happens to have the most scattered points on it.
I re-did my entire system from before. And after doing it, I realised that after the ripple occured, my fractured pieces still continue to bounce.
Not knowing why, I consulted Eric for advice. He told me that the most logical reason he can think of is because I added a force to force the pieces up and I also added another force to force the pieces down. Hence, that results in the bouncing in mid-air effect.
He told me to try to work simple if I wanted to work with groups.
Hence, I sat down thought through how I wanted it to be.
And suddenly I realised, since I already defined color inside dops, why don't I use that group to force the pieces to go up and then add a gravity node and force the pieces down after that? It may sound the same, but the group which is created based on color takes in the pieces based on the color value. Which in this case is driven by the a torus-like shape which is animated against time. Hence, some pieces which are affected by the group will go out of the group once they lose their color values. Hence, I could have more control.
I proceed on in that direction. For the gravity force pushing the pieces down, I went with the same expression that groups the pieces based on their position data.
And I will post some test videos below.
Anyway, after making sure that looks decent, I proceeded on with the second layer of the terrain.
I realised that using the same settings for the smaller terrain portion will not work for the bigger one. More settings needed to be tweaked. Or maybe its because of the piece size. Who knows?
Anyways, I played with the glue value, put that to 0. I changed the rotational stiffness and the friction.
I also increased the force that pushes the pieces upwards and decrease the forces that pushes the pieces downwards. I just played with it and hopefully I could show Steven something decent if he comes in tomorrow.
Tuesday, July 19, 2011
Day 35
Today, I continued with the ripple effect. I showed Mr Ari my new camera angle and he said it will not work out for him. As the turn is too sudden.
Hence, back to square one. I went back and re-did all of the timings of the camera work in my previs. I managed to finish it today. I then set up the ripple effect file hierarchy from the previous file.
I only can manage to finish it just before dops. Will continue tomorrow.
Hence, back to square one. I went back and re-did all of the timings of the camera work in my previs. I managed to finish it today. I then set up the ripple effect file hierarchy from the previous file.
I only can manage to finish it just before dops. Will continue tomorrow.
Day 34
Today we were caught on camera!
Cool! That was a nice start.
Back to work, today I went in and realised that my renders were so screwed up. I prepared 3 renders for today and only 1 managed to finish. God.
Anyway, I emailed Steven with that render and also the image which I rendered in HD with glow and stuff.
And he told me that my simulation needed a lot more work. Things such as the particle trail, the front flickering of smoke etc.
He advised me to focus on my shattering effect first instead.
I went with his advice and continued on my shattering effect.
I found that my existing camera angle was kind of cheesy and so I asked Bryan
for some advice.
He gave me some ideas on re-positioning my camera angle and it looked much better than my previous one.
I am not sure if I am allowed to change camera angles halfway through production.
And I know that I am working in the really wrong way.
But anyways, I decided to change it as it will look much better if I put that in my reel.
I spend the whole day tweaking the camera angle and setting up the shattering hierarchy I had in my other file.
I haven't got a chance to playblast the new camera angle. Will do when I have the time. But trust me, is much much nicer than my previous one.
Cool! That was a nice start.
Back to work, today I went in and realised that my renders were so screwed up. I prepared 3 renders for today and only 1 managed to finish. God.
Anyway, I emailed Steven with that render and also the image which I rendered in HD with glow and stuff.
And he told me that my simulation needed a lot more work. Things such as the particle trail, the front flickering of smoke etc.
He advised me to focus on my shattering effect first instead.
I went with his advice and continued on my shattering effect.
I found that my existing camera angle was kind of cheesy and so I asked Bryan
for some advice.
He gave me some ideas on re-positioning my camera angle and it looked much better than my previous one.
I am not sure if I am allowed to change camera angles halfway through production.
And I know that I am working in the really wrong way.
But anyways, I decided to change it as it will look much better if I put that in my reel.
I spend the whole day tweaking the camera angle and setting up the shattering hierarchy I had in my other file.
I haven't got a chance to playblast the new camera angle. Will do when I have the time. But trust me, is much much nicer than my previous one.
Friday, July 15, 2011
Day 31
Today, I continued doing my meteor shot. Hopefully today will be my last and final day tweaking the shot. I realised my render for my meteor trail with motion blur is still going on. It took 22hours( and still counting ) and it is still has 7 frames more to go. I am rendering 72 frames by the way. Okay, so I will put that aside.
I continued with the glow effect for my meteor. I managed to get it looking like this:
After finding that it looked quite decent, I proceeded on to rendering the meteor rock with smoke. And it looked like this:
Below is the result with a couple of iterations:
I found that it looked pretty decent. Now I proceed on rendering it at HD 720.
The renders from yesterday aren't done yet. Hence, I will upload the renders on Monday. Meanwhile, I will pass in the render with the new glow geometry and also render that at HD 720 with motion blur.
I continued with the glow effect for my meteor. I managed to get it looking like this:
After finding that it looked quite decent, I proceeded on to rendering the meteor rock with smoke. And it looked like this:
Below is the result with a couple of iterations:
I found that it looked pretty decent. Now I proceed on rendering it at HD 720.
The renders from yesterday aren't done yet. Hence, I will upload the renders on Monday. Meanwhile, I will pass in the render with the new glow geometry and also render that at HD 720 with motion blur.
Day 30
Today, I continued with the meteor. I consulted Mr Ari with regards to the glow of the meteor and the flickering of the smoke. He told me that I could do the glow in post or add a geometry light to the rock. I could then add a glow shader to the geometry light to further enhance it.
For the motion blur, he told me the problem that I had before with the motion blur was because I didn't increase the pixel samples in my mantra. After he helped me increase the pixel samples, The motion blur artifacts went away. ( But the render time increase by 3 times I think )
Above is a incomplete render of smoke with the motion blur. I couldn't wait for it to finish. Anyway, I couldn't visualize the smoke flickering now as it is not showing in the viewport. Let's hope motion blur could at least do something to fix that problem hopefully. After that I moved on to do the glow effect for the rock. I just messed around with the glow shader and the light intensity of the geometry light.
After that Charles gave a very interesting class about expressions. The class was more directed towards using expressions to do animations of objects. Like for example, animating objects using sine, cosine functions etc. That was all about what I have done today. Hopefully more tomorrow.
For the motion blur, he told me the problem that I had before with the motion blur was because I didn't increase the pixel samples in my mantra. After he helped me increase the pixel samples, The motion blur artifacts went away. ( But the render time increase by 3 times I think )
Above is a incomplete render of smoke with the motion blur. I couldn't wait for it to finish. Anyway, I couldn't visualize the smoke flickering now as it is not showing in the viewport. Let's hope motion blur could at least do something to fix that problem hopefully. After that I moved on to do the glow effect for the rock. I just messed around with the glow shader and the light intensity of the geometry light.
After that Charles gave a very interesting class about expressions. The class was more directed towards using expressions to do animations of objects. Like for example, animating objects using sine, cosine functions etc. That was all about what I have done today. Hopefully more tomorrow.
Subscribe to:
Posts (Atom)