Subject:
|
Re: Dat explorer
|
Newsgroups:
|
lugnet.cad
|
Date:
|
Thu, 16 Sep 1999 19:50:14 GMT
|
Viewed:
|
521 times
|
| |
|
|
Kevin Loch <kloch@opnsys.com> wrote in message news:FI5yLw.5p6@lugnet.com...
> In lugnet.cad, John VanZwieten writes:
> > A few suggestions:
> > Ability to look NW,NE,SW,SE, or even better input degrees of rotation, with • 0
> > being north.
> > Ability to move by user-adjustable amount. It's irritating when it takes 5
> > moves just to get inside the building.
>
> This is possible, but you would loose most of the benifit of "caching" the
> previously rendered images, since there would be so much freedom. I'll start
> with adding larger jump options for the movements. By keeping those factors • of
> 50 it won't create new views. I would also like to have relative controls
> (left,right, forward, reverse) instead of n,s,e,w. That would add • significant
> calculations to the shell script and would probably require moving it to C.
Even just the four diagonal directions would be great, and would only double
the number of possible images. And factors of 50 would be fine for moving.
> > Some way of giving model authors credit on the page.
>
> That's actually not that hard to do.
>
> > Increase the value of "amb" in the pov file to brighten the models.
>
> Ok, I'm just learning povray syntax so I'll look at it.
> does "amb" work everywhere? even inside closed spaces?
> right now I'm using one light source in the "flashlight" position.
> That's the only way I know to guarantee ilumination in every space.
I think the ambient light value works everywhere, even in closed spaces. But
I can't say I've tried it. The diffuse value also affects the light getting
to different parts of the model.
> >
> > I imagine you already have some of this stuff in the works. Great start!
> >
> > Another possible future enhancement would be the ability to accept any .dat
> > file as input, on the fly. It would be pretty awesome if someone could • click
> > on a Datsville image map and have that .dat file loaded into Dat Explorer • for
> > a virtual tour.
>
> Well, you could manually change the hyperlinks to call the appropriate
> model name (http://www.brickshelf.com/cgi-bin/mkpov.cgi?model=grnhouse would
> call up the green house model).
> Currently adding a dat file requires running it through l3p, which only
> runs on wintel. After that I strip everything after the object line,
> and an entry has to be made in (internal) models.txt with the model name,
> starting coordinates and look coordinates, url for linking to source, etc.
>
> That's not exactly an automatic process. I suppose if l3p was ported to
> FreeBSD I could automate it with a temporary model name.
>
> > Do you have any idea what POV-Ray is actually doing when it is "parsing"? • It
> > occured to me that if parsing is model- rather than view-dependent,
> > theoretically parsing could be done just once, which would greatly reduce
> > render time. This is probably a question for the POV-Ray newsgroups.
>
> It is definately not view dependent. I'm going to go through the povray
> source and figure out what if anything can be saved to a binary file after
> parsing to bypass those steps in subsequent rendering.
From news.povray.org's povray.general newsgroup:
John VanZwieten wrote:
>
> Is it necessary for POV-Ray to parse a file separately for each view of the
> same scene? Is there any way to "save" the result of the parsing to use in
> repeated raytracings from different views?
>
> Thanks in advance for any help with this.
>
> -John VanZwieten
There is no simple way how to do this.
POV-Ray is an offline program which reads
its input, computes a pretty output and
terminates. There is an animation loop,
but it is based on reparsing the scene.
I noticed some debates on a binary format
(this is probably what you mean) but it
was never implemented (binary triangle
meshes are the only exception). Anyway,
a binary format would not lead to a
significant parsing speedup.
You asked for "any way". OK, there is a
way how to do a camera animation without
reparsing the scene. This requires some
programming. You have to write a program
which mimicks POV-Ray but keeps running
unless told to terminate. Such an
interactive POV-Ray must have an option
to parse a new file after rendering a
frame, without destroying the original
scene which is still in memory. The new
file will contain just the new camera.
That's it.
(from Tomas Plachetka )
-John Van
|
|
Message has 1 Reply:
 | | Re: Dat explorer
|
| Povray sucks up 800+MB of virtual memory while parsing Datsville. If we saved some of those memory structures as binary maped files and povray could work against those the next time it rendered, It should speed it up alot. I'm assuming that most of (...) (25 years ago, 16-Sep-99, to lugnet.cad)
|
Message is in Reply To:
| | Re: Dat explorer
|
| (...) This is possible, but you would loose most of the benifit of "caching" the previously rendered images, since there would be so much freedom. I'll start with adding larger jump options for the movements. By keeping those factors of 50 it won't (...) (25 years ago, 16-Sep-99, to lugnet.cad)
|
8 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
