 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm curiouse if there is a program out there that will parse povray
files, and unfold loops and the such into what they'd look like if not
within macro's. Basically, I'd like to be able to run some of my scenes
thru this, to generate the huge text files, that I can then import into
something like moray. A prime example would be something like the
tree.inc files. I'd like to be able to run thru a file that has like 10
of them, and have the output have the actual objects to create the
tree..
Not quite sure if I'm making sence, but hopfully someone get's the
drift..
Thomas Charron
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What your saying is you want the pov macros to act
like an object generating program.
Other than that I can't help you.
That would be nifty.
K.Tyler
Thomas Charron wrote:
> I'm curiouse if there is a program out there that will parse povray
> files, and unfold loops and the such into what they'd look like if not
> within macro's. Basically, I'd like to be able to run some of my scenes
> thru this, to generate the huge text files, that I can then import into
> something like moray. A prime example would be something like the
> tree.inc files. I'd like to be able to run thru a file that has like 10
> of them, and have the output have the actual objects to create the
> tree..
>
> Not quite sure if I'm making sence, but hopfully someone get's the
> drift..
>
> Thomas Charron
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Charron wrote:
>
> I'm curiouse if there is a program out there that will parse
> povray
> files, and unfold loops and the such into what they'd look like if not
> within macro's. Basically, I'd like to be able to run some of my
> scenes
> thru this, to generate the huge text files, that I can then import
> into
> something like moray. A prime example would be something like the
> tree.inc files. I'd like to be able to run thru a file that has like
> 10
> of them, and have the output have the actual objects to create the
> tree..
>
> Not quite sure if I'm making sence, but hopfully someone get's the
> drift..
>
> Thomas Charron
I don't quite understand your question, but it brings up another
question with me. You mention loops and the tree.inc, and, as far as I
understand you want to extract code from these loops. What would be the
advantage (sorry if I seem stupid - wait till you see my face 8=)
The reason I ask this is that I don't understand what should be better:
a loop or a heap of code. I tried tree.inc and was impressed, but I
needed another kind of tree. First I fiddled around a bit with the
declarations, but that brought me no where. Being new to POVray, but not
very new anymore with programming I just wrote me a program that
generated some weird looking random trees that were just what I needed.
Only thing is that it generated plain code, so some trees could take up
about 1Mb of code! The average tree would be 200-300Kb, but a fullgrown
'Giant of the Woods' needs much more. Obviously this takes much more
time to parse. Or not?
If anyone here is interested in a freak-tree let me know.
Regards,
Remco
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe you want to check out Thomas Baier's POB-SDK. (Find a link to his page
on the Moray Download page.)
It includes a custom made version of POV-Ray (for DOS) which reads a POV
script and outputs everything in it into a POB file (which is a binary
format). Another tool in the package can read such a POB file and generate a
POV script from it. This resulting script does not have any whiles, ifs etc.
but only declarations of the objects that were generated by the actual first
script.
Hope it helps,
Johannes.
Thomas Charron wrote in message <35ACEE2E.723C3E5C@nermail.ups.com>...
> I'm curiouse if there is a program out there that will parse povray
>files, and unfold loops and the such into what they'd look like if not
>within macro's. Basically, I'd like to be able to run some of my scenes
>thru this, to generate the huge text files, that I can then import into
>something like moray. A prime example would be something like the
>tree.inc files. I'd like to be able to run thru a file that has like 10
>of them, and have the output have the actual objects to create the
>tree..
>
> Not quite sure if I'm making sence, but hopfully someone get's the
>drift..
>
> Thomas Charron
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Remco de Korte wrote:
> I don't quite understand your question, but it brings up another
> question with me. You mention loops and the tree.inc, and, as far as I
> understand you want to extract code from these loops. What would be the
> advantage (sorry if I seem stupid - wait till you see my face 8=)
>
Well, all's great and well, untill you want to get these objects into a
modeller. I have yet to see a modeller that can deal with Pov Macros, so
therefore means one cannot import these objects. Object placement by hand
is all great and good, but theres a point when it just get's two darned
complex. In the past, I've put little cubes naming them 'Tree1', etc, doing
an extract, then going in with a text editor, but it'd be a whole lot easier
to be able to just import them into the modeller..
> The reason I ask this is that I don't understand what should be better:
> a loop or a heap of code. I tried tree.inc and was impressed, but I
> needed another kind of tree. First I fiddled around a bit with the
> declarations, but that brought me no where. Being new to POVray, but not
> very new anymore with programming I just wrote me a program that
> generated some weird looking random trees that were just what I needed.
>
Exactly what I ended up doing, but I'd prefer not to have to rewite
every single include file to produce real objects instead of macros.. ;-P
> Only thing is that it generated plain code, so some trees could take up
> about 1Mb of code! The average tree would be 200-300Kb, but a fullgrown
> 'Giant of the Woods' needs much more. Obviously this takes much more
> time to parse. Or not?
>
Of course, but that's why we all need bigger, moreMOREMOOORRREEE
PPPOOOWWWEEERR!! ;-P
> If anyone here is interested in a freak-tree let me know.
Sure, I'll trade for mine.. What did you use to do it?
Thomas Charron
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
> Maybe you want to check out Thomas Baier's POB-SDK. (Find a link to his page
> on the Moray Download page.)
>
> It includes a custom made version of POV-Ray (for DOS) which reads a POV
> script and outputs everything in it into a POB file (which is a binary
> format). Another tool in the package can read such a POB file and generate a
> POV script from it. This resulting script does not have any whiles, ifs etc.
> but only declarations of the objects that were generated by the actual first
> script.
Hrm.. Ya, this would do it.. I'd only need to do it once, then import the
object into the modeller from the Povray script generated.. Maybee a couple of
times for random effect scripts.. Thanks for the tip! I'll keep ya posted..
Thomas Charron
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Charron wrote in message <35AE262D.64CC0984@nermail.ups.com>...
> Hrm.. Ya, this would do it.. I'd only need to do it once, then import
the
>object into the modeller from the Povray script generated.. Maybee a
couple of
>times for random effect scripts.. Thanks for the tip! I'll keep ya
posted..
Actually, have you thought about using UDOs?
UDOs work like this:
You have two files: one UDO file and one INC file.
The UDO file follows a certain standard and describes how the object should
look in Moray.
The INC file can contain *any* POV-Ray compliant syntax (even while-loops,
other includes etc.) and describes how the object looks in POV-Ray.
In Moray you manipulate (translate, scale, rotate, even texture) the object
representation as it is read from the UDO file. But when exporting, Moray
doesn't export this UDO description or any POV-Ray primitives or such, but
simply an include directive to include the INC file (with all the
manipulations applied).
This way, you can have *any* POV-Ray object (or collection of objects) as an
object in Moray.
The only drawback is, that you have to write the UDO file by hand, to create
an adequate Moray-representation of your object. But that isn't to hard
either, since UDO files are text files and essentially only contain a list
of 3D vertices and a list of edges between them.
Check it out!
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, that's all and well, but it doesn't solve the fact that I want to
generate some of these objects from publically available .INC files that use
macro's to create the objects. I COULD write my own, but to be totally honest,
I don;t have the time with 5 side-projects, and trying to get one or two entries
to irtc finished up..
Thomas Charron
Johannes Hubert wrote:
> Thomas Charron wrote in message <35AE262D.64CC0984@nermail.ups.com>...
> > Hrm.. Ya, this would do it.. I'd only need to do it once, then import
> the
> >object into the modeller from the Povray script generated.. Maybee a
> couple of
> >times for random effect scripts.. Thanks for the tip! I'll keep ya
> posted..
>
> Actually, have you thought about using UDOs?
>
> UDOs work like this:
>
> You have two files: one UDO file and one INC file.
> The UDO file follows a certain standard and describes how the object should
> look in Moray.
> The INC file can contain *any* POV-Ray compliant syntax (even while-loops,
> other includes etc.) and describes how the object looks in POV-Ray.
>
> In Moray you manipulate (translate, scale, rotate, even texture) the object
> representation as it is read from the UDO file. But when exporting, Moray
> doesn't export this UDO description or any POV-Ray primitives or such, but
> simply an include directive to include the INC file (with all the
> manipulations applied).
>
> This way, you can have *any* POV-Ray object (or collection of objects) as an
> object in Moray.
>
> The only drawback is, that you have to write the UDO file by hand, to create
> an adequate Moray-representation of your object. But that isn't to hard
> either, since UDO files are text files and essentially only contain a list
> of 3D vertices and a list of edges between them.
>
> Check it out!
>
> Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas Charron wrote in message <35AF7974.6A2C5A24@nermail.ups.com>...
> Well, that's all and well, but it doesn't solve the fact that I want to
>generate some of these objects from publically available .INC files that
use
>macro's to create the objects. I COULD write my own, but to be totally
honest,
>I don;t have the time with 5 side-projects, and trying to get one or two
entries
>to irtc finished up..
I don't see the problem :-) since the INC file of the UDO/INC pair can
contain any POV-Ray code, even #includes or even macros (POV 3.1 etc.)
The only work would be to write the UDO file, with a nice and suitable
representation of the object in Moray (made up out of vertices and
connecting edges).
I guess that writing such an UDO even for a complex object can be faster
than going through a lot of conversion steps.
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
