
Awesome
Off the top of my headOnoSendai wrote: I'm still thinking about how to handle the volume data formats etc...
Any more suggestions are welcome!
and a woman or two!manitwo wrote:you can be really proud of yourself - so go and get yourself a beer now - you deserve it
lol he was making a not so subtle reference to the book "The Hitchhiker's Guid to the Galaxy" where mice are actually the most intelligent beings on Earth and if I remember right they build planets, or at least someone builds planets, and the most fun parts to make are the coastlines and fjords.Lord of the Rings Junkie wrote:Hold your horses guys, an Earth-sized sphere is a far cry from a planet with full terrain! Awesome feature though, absolutely cannot wait!:D What's next, a scale Sun model 93 billion miles from Earth?:) (Hopefully it wouldn't take light 8 minutes to reach your render...)lol
[Edit] Both linear and rotational motion blur would be cool things to see in 0.9
Does this means that a new generic Indigo particle Format is needed, that the 3D aplications have to export to (via new developed export Plugin)???OnoSendai wrote:It would be relatively simple to read in a list of particles, and 'splat' them into a volume map, using some kind of 3d filter for each particle (e.g. gaussian, step function, etc..)
Then the volume map could be used for rendering.
Alternatively the particles could be stored in their own data structure, which might be better for sparser sets, but that would be a bit trickier to code.
well i think most, if not all, 3d programs used here have particles so i think its a matter of translating particle position/density and maybe even speed and direction into an Indigo particle format. or if particle density could create a 3d grid (maybe what tinman999 was talking about?). this is really cool.ZomB wrote:Does this means that a new generic Indigo particle Format is needed, that the 3D aplications have to export to (via new developed export Plugin)???OnoSendai wrote:It would be relatively simple to read in a list of particles, and 'splat' them into a volume map, using some kind of 3d filter for each particle (e.g. gaussian, step function, etc..)
Then the volume map could be used for rendering.
Alternatively the particles could be stored in their own data structure, which might be better for sparser sets, but that would be a bit trickier to code.
This would perhaps give you (Ono) the most flexibility for your interaction with this particle files.... ergo better and faster visual results.
The Drawback will be the developement time for each 3D application ...
Users browsing this forum: No registered users and 145 guests