Can blender do this :D
Moderators: jesterKing, stiv
-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
Can blender do this :D
http://graphics.cs.cmu.edu/projects/bdt ... x_high.avi
http://graphics.cs.cmu.edu/projects/bdtree/
Yeah yeah I know, NO ! But one can dream. He explains it so well when showing it to.
http://graphics.cs.cmu.edu/projects/bdtree/
Yeah yeah I know, NO ! But one can dream. He explains it so well when showing it to.
Re: Can blender do this :D
Actually, YES, just read the paper and write a script to do it. It must not be that hard, right.Money_YaY! wrote:Yeah yeah I know, NO !.
Martin
Life is what happens to you when you're busy making other plans.
- John Lennon
- John Lennon
Re: Can blender do this :D
I read the paper, not so easy (high computations). But feasible indeed.theeth wrote:Actually, YES, just read the paper and write a script to do it. It must not be that hard, right.Money_YaY! wrote:Yeah yeah I know, NO !.
Martin
-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
Re: Can blender do this :D
Ha ha I knew you would say thattheeth wrote:Actually, YES, just read the paper and write a script to do it. It must not be that hard, right.Money_YaY! wrote:Yeah yeah I know, NO !.
Martin

-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
In the vid he says that their custon JAVA app uses OpenGL to render and do all of the work in 15 hours for all of the chairs comparied to 7 weeks of what it takes in a basic physics app like Havok.macouno wrote:It seems like mostly he gets it to render so quickly cause he uses opengl rendering no???
And we might get that in some way in the future
As for OpenGL, OpenGL has so much new stuff that I see it replaceing basic software rendering but it is something that is not cross platform enough and requires a great happy 200$ Graphics card.
Anyone that has not watched to movie should it explains so much in it.
I must not be understanding your post, because OpenGL is cross platform (yes even the pixel shader stuff) and you can do pixel shaders with cards that are under $100 canadian easily, and they are becoming increasingly the defacto video card computers come with. (GFX 5200 in this instance)Money_YaY! wrote:As for OpenGL, OpenGL has so much new stuff that I see it replaceing basic software rendering but it is something that is not cross platform enough and requires a great happy 200$ Graphics card.
-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
Eh if the 100$ card does the job then so be it. It is just how to get the same code to render the same GL picture on every platform with out to many hacks that break the cross compatibility.IoN_PuLse wrote:I must not be understanding your post, because OpenGL is cross platform (yes even the pixel shader stuff) and you can do pixel shaders with cards that are under $100 canadian easily, and they are becoming increasingly the defacto video card computers come with. (GFX 5200 in this instance)Money_YaY! wrote:As for OpenGL, OpenGL has so much new stuff that I see it replaceing basic software rendering but it is something that is not cross platform enough and requires a great happy 200$ Graphics card.
Anyway, I would love to see Blender render fromthe CG card as testing out animation blocks would be so much faster, and rendering in gernral would be faster. I have seen raytraceing before on a CG card though still slow.
Eh it just takes someone to try it now and to know how to do it. That is the difficult part.
There seems to be some confusion about what the video is about.
Drawing a gazillion chairs isn't what makes the video impressive. It's not especially difficult to do with any zBuffer renderer (which is what OpenGL is).
What is primarily being demonstrated is a collision system. That is, the computer is testing the objects to see if they collide with one another. You don't want to test every polygon in the scene with every other polygon in the scene. Not only is it computationally expensive, but it's a waste of effort - most polygons aren't going to be touching anything at all.
On the other hand, testing to see if spheres collide with each other is an easy operation. So spheres are often used as bounding areas around objects. The problem is that spheres don't fit objects very tightly. So if a sphere around an object collides with another object, that doesn't necessarily mean that the objects collide with each other. (On the other hand, if they don't collide, you're guaranteed that they don't touch).
So everything in the scene gets a bounding sphere around it, and it's easy to ignore the stuff that isn't touching. To solve the problem about the spheres being too loose fitting, when a collision is detected between two objects, you generate more (and smaller) spheres around the objects that are colliding. That way, you can quickly determine which parts of the geometry to ignore.
This continues until it's cheap enough to just test the polygons to see what's intersecting what. It allows you to quickly determine what parts of the scene to ignore, and only concentrate on the interesting parts. Since (even with a massive amount of objects) only a small number of surfaces are actually colliding with one another, even very complex scenes can be resolved fairly quickly.
All that is fairly well known, and implemented in most physics systems. The video details clever ways to do this culling even faster.
Drawing a gazillion chairs isn't what makes the video impressive. It's not especially difficult to do with any zBuffer renderer (which is what OpenGL is).
What is primarily being demonstrated is a collision system. That is, the computer is testing the objects to see if they collide with one another. You don't want to test every polygon in the scene with every other polygon in the scene. Not only is it computationally expensive, but it's a waste of effort - most polygons aren't going to be touching anything at all.
On the other hand, testing to see if spheres collide with each other is an easy operation. So spheres are often used as bounding areas around objects. The problem is that spheres don't fit objects very tightly. So if a sphere around an object collides with another object, that doesn't necessarily mean that the objects collide with each other. (On the other hand, if they don't collide, you're guaranteed that they don't touch).
So everything in the scene gets a bounding sphere around it, and it's easy to ignore the stuff that isn't touching. To solve the problem about the spheres being too loose fitting, when a collision is detected between two objects, you generate more (and smaller) spheres around the objects that are colliding. That way, you can quickly determine which parts of the geometry to ignore.
This continues until it's cheap enough to just test the polygons to see what's intersecting what. It allows you to quickly determine what parts of the scene to ignore, and only concentrate on the interesting parts. Since (even with a massive amount of objects) only a small number of surfaces are actually colliding with one another, even very complex scenes can be resolved fairly quickly.
All that is fairly well known, and implemented in most physics systems. The video details clever ways to do this culling even faster.
-
- Posts: 442
- Joined: Wed Oct 23, 2002 2:47 pm
dcuny wrote:There seems to be some confusion about what the video is about.
Drawing a gazillion chairs isn't what makes the video impressive. It's not especially difficult to do with any zBuffer renderer (which is what OpenGL is).
What is primarily being demonstrated is a collision system. That is, the computer is testing the objects to see if they collide with one another. You don't want to test every polygon in the scene with every other polygon in the scene. Not only is it computationally expensive, but it's a waste of effort - most polygons aren't going to be touching anything at all.
On the other hand, testing to see if spheres collide with each other is an easy operation. So spheres are often used as bounding areas around objects. The problem is that spheres don't fit objects very tightly. So if a sphere around an object collides with another object, that doesn't necessarily mean that the objects collide with each other. (On the other hand, if they don't collide, you're guaranteed that they don't touch).
So everything in the scene gets a bounding sphere around it, and it's easy to ignore the stuff that isn't touching. To solve the problem about the spheres being too loose fitting, when a collision is detected between two objects, you generate more (and smaller) spheres around the objects that are colliding. That way, you can quickly determine which parts of the geometry to ignore.
This continues until it's cheap enough to just test the polygons to see what's intersecting what. It allows you to quickly determine what parts of the scene to ignore, and only concentrate on the interesting parts. Since (even with a massive amount of objects) only a small number of surfaces are actually colliding with one another, even very complex scenes can be resolved fairly quickly.
All that is fairly well known, and implemented in most physics systems. The video details clever ways to do this culling even faster.
Ok with all of that said, is it possible to do within blender? Or is it just all talk?
Blender use already solid lib for collisions in game engine which implement the basic algo. The new method presented in this paper is more advanced than what is present in solid directly, but that could be added yes. It is however quite some work.Money_YaY! wrote:dcuny wrote:There seems to be some confusion about what the video is about.
Drawing a gazillion chairs isn't what makes the video impressive. It's not especially difficult to do with any zBuffer renderer (which is what OpenGL is).
What is primarily being demonstrated is a collision system. That is, the computer is testing the objects to see if they collide with one another. ...
All that is fairly well known, and implemented in most physics systems. The video details clever ways to do this culling even faster.
Ok with all of that said, is it possible to do within blender? Or is it just all talk?