 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I tell a lie, it's a flash control deerrrr, still, it's pretty generic.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Of course http://earth.imagico.de/5gp/ is a perfect example of tiling large
images.
All irrelevant though unless people are interested, one taker so far.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MattM" <mat### [at] hotmail com> wrote:
> Well xmas it is then (I was open to any theme) I think ray-tracers all get
> secretly exciting about rendering baubles etc when it comes down to it.
Andrew is going to get over-excited :)
> I'm glad you've had some experience of this, I think rendering resources is
> a potential obstacle, as long as individual contributions are sensible, you
> know, not using a 2MB mesh for each snowdrop etc we could create quite a
> large pic. Also we could just render portions of the image then stitch them
> together to get around that problem.
One problem is that everyone will want to give their best and that generally
means longish render times for each object. Especially if they are *shiny*
and interact with each other. But that is the coordinators problem :) It
might be a good idea if you defined a scale that everyone should use and a
few ground rules. Most of my images contain a Poser figure or two and those
meshes with their accompanying image maps can add up to large files, beware.
a while) as he organised the Moray Tribute. Search for it in p.m.w and
p.m.b.
> Your object sounds ideal.
> I was going to mention some sort of standard to make things easy which is
> basically to provide an .inc file with just the object/s (no scene, global
> stuff etc) with details of what object/macro name to call from the main
> file).
Good Luck getting a consensus from this lot :)
> If you can see my email, I'd be happy to accept it there.
Can do but I'll wait untill I get the ground rules
> thanks
>
> Now we need more takers! I mean if we're thinking gigapixel images (yes I
> know pov has a limit) we need many many objects!
>
> (It did cross my mind that a great image would rival/beat
> themilliondollarwebsite in terms of a users interest, advertising etc, but
> I'm not suggesting this to make money, its in the spirit of collaborative
> art!!)
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You're right actually, I don't want to compromise on this, I'd like as much
detail as people want to put in.
So to overcome that we'll have to render many images and stitch them
together. That way we can circumvent the limits on memory etc (with careful
thought there shouldn't be many artifacts visible with shadows of objects
overlapping others as each object will have a fairly small discrete area
within the image.
As a scale the final object should fit nicely into a <0,0,0> <1,1,1> box.
Must use #local not #declare (unless you've really come up with a good
uniquename) to avoid name clashes.
So fitting in the box and in the #include requirement (I mentioned
earlier)should make a pretty straightforward guideline.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MattM" <mat### [at] hotmailcom> wrote:
> You're right actually, I don't want to compromise on this, I'd like as much
> detail as people want to put in.
>
> So to overcome that we'll have to render many images and stitch them
> together. That way we can circumvent the limits on memory etc (with careful
> thought there shouldn't be many artifacts visible with shadows of objects
> overlapping others as each object will have a fairly small discrete area
> within the image.
>
> As a scale the final object should fit nicely into a <0,0,0> <1,1,1> box.
> Must use #local not #declare (unless you've really come up with a good
> uniquename) to avoid name clashes.
>
> So fitting in the box and in the #include requirement (I mentioned
> earlier)should make a pretty straightforward guideline.
Maybe MegaPOV XRS would be a viable rendering solution for this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yeah I did realize that it's windows only, I haven't look at other viewers
> and how cross platform they are (and how easy it is to create content).
>
> Anyone any experience of other similar viewers?
>
>
Gigapxl uses Google Maps web software, it's free to use and it seems to
have a quite complete API. Gigapxl had to add some hooks for it to work
on a flat image instead of a map with mercator projection :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "MattM" <mat### [at] hotmailcom> wrote:
>> You're right actually, I don't want to compromise on this, I'd like as much
>> detail as people want to put in.
>>
>> So to overcome that we'll have to render many images and stitch them
>> together. That way we can circumvent the limits on memory etc (with careful
>> thought there shouldn't be many artifacts visible with shadows of objects
>> overlapping others as each object will have a fairly small discrete area
>> within the image.
>>
>> As a scale the final object should fit nicely into a <0,0,0> <1,1,1> box.
>> Must use #local not #declare (unless you've really come up with a good
>> uniquename) to avoid name clashes.
>>
>> So fitting in the box and in the #include requirement (I mentioned
>> earlier)should make a pretty straightforward guideline.
>
> Maybe MegaPOV XRS would be a viable rendering solution for this?
>
>
I have a better rendering system, it's currently quite messy (lots of
manual stuff needed to get a scene going!) but if I get time and
motivation (and this project seems to give me the latter) I could work
on automating it more.
Tile rendering and animations are both supported (including combining
both; that is splitting each frame in tiles). Resuming a render is
supported (you *don't* want to know the hacks I had to use on POV-Ray
code to get that working; I can't wait for POV 3.7 which uses a state file).
Currently hosted by IMP, and with few users (but one of them has a few
8-core machines): http://impfarm.imp.org/boinc/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Cool Chris, my everyday job involves writing such code. I think we'd
> definitly have to create a dhtml version for everyone to view.
>
> In fact look at this...
>
> http://www.gigapan.org
>
> It's very much like google earth, upload your own gigapixel images and
> browse them, no controls in sight.
>
>
Wow how annoying. I can't browse the image on the front page for even a
few seconds, because it keeps scrolling/zooming on its own and changing
to a different image. That's quite a bad idea for a demo :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well here's the crazy idea, anyone interesting in contributing to a large
> image just for fun. I'm thinking along the lines of every participant
> creating an object to be placed into the image. For instance as we're on
> our way to xmas how about a toyshop with a myriad of toys on the shelf each
> created by individual users.
Threadbump - anyone interested?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bumping the thread. Nobody interested?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
