|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 31 Dec 2004 13:12:46 +0100, Bernd Fuhrmann <Sil### [at] gmxde>
wrote:
> Why not? It isn't that difficult. People write XHTML, MathML and even
> SVG by hand. At least I do. So why not POVRay?
You know, there are a few not technical users of POV-Ray. While average
"artist" can easily write and understand sphere{0 r scale x*4 pigment{Red}}
anything more complicated would make understanding harder.
> It would be possible to write material libraries, object libraries and
> so on without clobbering the global namespace.
You have material and object libraries nowadays in include files.
Can you point me an example of useful namespace application within POV-Ray
scene from average unskilled user point of view?
> It would become possible to access the camera settings to adjust certain
> values.
See screens.inc include file solutions.
> This would make the implementation of HUD systems possible
Head Up Displays you mean? Which application you mean exactly?
> (useful if you want to mark or label certain things in your scene).
? Anything you can't do currently?
> One could even convert whole models to meshes and apply mesh
> modificators on them. This is AFAIK not yet possible in POVRay.
That depends what you mean by "convert" and "modificators".
ie. http://www.geocities.com/SiliconValley/Lakes/1434/images/createmesh.jpg
> Ok, maybe some of these things can be done in POVRay file format.
IMO that's not POV-Ray file format but POV-Ray features which makes things
possible.
> But if they can be done, how clean can they be done?
Some prefer question: how hard can they be done. I think writing simple
include file is easier than introducing new parser and changing habits of
large community.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:s1hat0h78j5s8q34g4e8308c8aubiv6230@4ax.com ABX wrote:
> Can you point me an example of useful namespace application within
> POV-Ray scene from average unskilled user point of view?
>
A problem I ran into several times is using multiple include files, where
in two or more inc's objects are defined with the same name.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31 Dec 2004 07:54:35 -0500, ingo <ing### [at] tagpovrayorg> wrote:
> > Can you point me an example of useful namespace application within
> > POV-Ray scene from average unskilled user point of view?
>
> A problem I ran into several times is using multiple include files, where
> in two or more inc's objects are defined with the same name.
And usually how hard it is to solve such issue?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Bernd,
"Bernd Fuhrmann" <Sil### [at] gmxde> wrote in message
news:41d51598@news.povray.org...
> Hi!
>
> I just thought if it might be possible to use XML to describe a scene.
> ... snip ...
> I'd like to know if there is already such a system planned or implemented.
It is already possible to use VRML to describe a scene (not a POVRay scene).
VRML has been about since about 1994.
There is a project working to convert it to an XML base (xVRML) as it was
originaly based on SGML principles. In fact I think they released an XML
schema for it way back in 2003.
It sounds like it might be of interest to you as it already supports flying
through scenes, which is the sort of thing you would need for use with a
head up display.
You can also bookmark 3d positions in a scene so that the user can fasttrack
the view point to those positions.
> ...snip ... Is anyone except me interested in implementing such a system?
> What do you think about this idea?
I think there are probably lots of people on the VRML news groups and in the
xVRML community that are interested in such a system.
I myself took a brief interest in this before discovering POVRay. I, like
you, am quite happy to dive into coding markup languages by hand, but what
put me off VRML (and the concept of using tagged markup languages for scene
description in general) is the enourmously verbose manner used to describe
an object.
As has already been mentioned, POVRays Scene Description Language provides a
highly elegant and concise yet flexible way to describe objects.
I found that even to describe relatively simple objects in VRML 1.0 was
cumbersome. It may have improved with the more recent versions of VRML, but
I think it's more down to the nature of markup languages. Nowadays I think
people probably use converters to generate anything but the simplest VRML
scenes, and even then I've never seen any VRML scenes that come close to the
sophistication of some of the newbie POVRay scenes posted on the povray
newsgroups.
>
> Thanks in advance
> Bernd Fuhrmann
So I think the concept of using an XML, VRML, xVRML or other tagged markup
language to describe 3D scenes has a place.
But I very much prefer the POVRay SDL for the sort of things you see POVRay
being used for and would direct anyone advocating changing it in the
direction of a tagged markup language to take a look at why VRML hasn't
grown into this space in the 10 years it's been about.
Regards,
Chris.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ABX wrote:
> You know, there are a few not technical users of POV-Ray. While average
> "artist" can easily write and understand sphere{0 r scale x*4 pigment{Red}}
> anything more complicated would make understanding harder.
I'm not saying that the whole primary file format of POVRay should be
changed. I just state that there should be a XML version of it. Or there
should at least be the ability to use a XML version. This can be done by
using XSLT. No change in POVRay is required. But it wouldn't make sense
if I programmed my own XSLT for that. So I looked for people that have
some interest in using XML for POVRay.
>>It would be possible to write material libraries, object libraries and
>>so on without clobbering the global namespace.
>
> You have material and object libraries nowadays in include files.
> Can you point me an example of useful namespace application within POV-Ray
> scene from average unskilled user point of view?
Ok, an example. Two people, A and B, work on car models. They both make
two good ones that you want to use in your scene. Both will get more
features in the future. So you will want to update them often. But there
is a problem: Both use equal names for different macros (CreateTire,
CreateEngine, and so on). As soon as you include both files from these
two authors you will have conflicts. When you solve them manually they
will return as soon as you upgrade your files. So you will have to
constantly solve name conflicts. Ok, this is feasible for two scene
files. But what, if you have thousands of cars (highway scene)? Welcome
to namespace hell!
This does not happen with XML: You would use for example use XSLT to
replace something like <car xmlns="http://www.cardesigner.com/volvo0001"
tiresize="50" color="Red" leftdoor="open" rightdoor="closed"/> with the
model of your car. There won't ever be any conflicts.
>>This would make the implementation of HUD systems possible
>
> Head Up Displays you mean? Which application you mean exactly?
I needed it when I rendered three dimensional graphics. I had to label
certain points. It was then neccessary to put all camera parameters into
global variables. I think it is a rather dirty solution.
>>(useful if you want to mark or label certain things in your scene).
>
You can do everything. You can even write a C++ compiler in POVRay if
you have enough sparetime. That's not the point. The point is: Can you
do it the clean way?
>>One could even convert whole models to meshes and apply mesh
>>modificators on them. This is AFAIK not yet possible in POVRay.
>
> That depends what you mean by "convert" and "modificators".
> ie. http://www.geocities.com/SiliconValley/Lakes/1434/images/createmesh.jpg
I am talking about structural conversion: Take a cone {<0,0,0> 1 <1,0,0>
2} and convert it to an approximation of triangles to apply mesh
modificators on it (like twisting, bending, etc.). It should be possible
to do so without losing your original cone markup. So conversion should
be done on the fly. POVRay won't be able to do this. Ok, POVRay can do
this if you encode that cone into some data structure. But that won't be
feasable if someone else wrote that code and you don't want to touch it.
>>Ok, maybe some of these things can be done in POVRay file format.
>
> IMO that's not POV-Ray file format but POV-Ray features which makes things
> possible.
True, I admit.
>>But if they can be done, how clean can they be done?
>
> Some prefer question: how hard can they be done. I think writing simple
> include file is easier than introducing new parser and changing habits of
> large community.
I'm not planning to change anyones habits. It is obvious that the design
of a XSLT script that is able to map all possible features of POVRay to
XML will take one month or two. Therefore I'm looking for people who are
interested in such an idea. I'd really like to develop some models,
materials and things for POVRay but I know that I'd go to namespace hell
for that. My scripts would be useless in a couple of years. XML is a
good way to assure compatibility.
Regards,
Bernd Fuhrmann
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37jat050gpl1jhjhfl290afmkdbivt0f7q@4ax.com>, abx### [at] abxartpl
says...
> On 31 Dec 2004 07:54:35 -0500, ingo <ing### [at] tagpovrayorg> wrote:
> > > Can you point me an example of useful namespace application within
> > > POV-Ray scene from average unskilled user point of view?
> >
> > A problem I ran into several times is using multiple include files, where
> > in two or more inc's objects are defined with the same name.
>
> And usually how hard it is to solve such issue?
>
> ABX
>
Actually, that 'could' be solved with something as simply as treating the
file itself as an object. I.e.:
File 1 (Fred.inc):
...
object Fred = {Sphere{<0,0,0>, 1}}
...
File 2 (MyBoxes.inc):
...
object Fred = {box{<-0.5,-0.5,-0.5>,<0.5,0.5,0.5>}
...
Instead of generating a parse error, you take any duplicates and make
then sub objects:
Fred.Fred
MyBoxes.Fred
If however, you only use one of the includes, then 'Fred' would
automatically resolve to the only one available. This would have no
effect on most scenes, since it only effects cases where more than one
definition is being used. Of course, it would need to ignore re-
definitions in the same file, so that only the 'final' state of the
includes objects are considered. If Fred was redefined five times in the
same include, only the last version would become valid, since that is all
the main scene would see anyway. Same with local definitions, though you
might need to include the concept of 'me.<object>' for clarity.
But really, just editing the names for your own purposes is not that big
a deal. Well, unless it is one of those million object tree includes one
of the tree maker utilities generates..... lol Just finding all the damn
names to change them in those is a nightmare.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <41d59f26$1@news.povray.org> , Bernd Fuhrmann
<Sil### [at] gmxde> wrote:
> I'm not saying that the whole primary file format of POVRay should be
> changed. I just state that there should be a XML version of it. Or there
> should at least be the ability to use a XML version. This can be done by
> using XSLT. No change in POVRay is required. But it wouldn't make sense
> if I programmed my own XSLT for that. So I looked for people that have
> some interest in using XML for POVRay.
Whatever argument for XML you can give, it applies for any other format.
The use of XML has been discussed to death before, and there are just no
arguments for it that do not apply to the current format just as well. As
such, there is no point to argue for XML. To the contrary, there are things
you can do in POV-Ray right now that would be incredibly difficult to
express in XML.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bernd Fuhrmann <Sil### [at] gmxde> wrote:
> Why not? It isn't that difficult. People write XHTML, MathML and even
> SVG by hand. At least I do. So why not POVRay?
Because there already is a language which is ten times easier to
write and understand.
> It would be possible to write material libraries, object libraries and
> so on without clobbering the global namespace.
If this is the problem, why is XML the solution?
The POV-Ray SDL is a *programming language*, XML is a markup language.
Trying to create a programming language with a markup language is not
the best possible idea.
> It would become possible to access the camera settings to adjust certain
> values. This would make the implementation of HUD systems possible
> (useful if you want to mark or label certain things in your scene).
And XML is the best solution for this because...?
> One could even convert whole models to meshes and apply mesh
> modificators on them. This is AFAIK not yet possible in POVRay.
And how on earth does XML make this any easier? Does XML have some
magic which will allow you to tesselate any given surface?
> Ok, maybe some of these things can be done in POVRay file format. But if
> they can be done, how clean can they be done?
It is aknowledged that the current SDL has reached its practical limits
and that a better language may be necessary, but XML is certainly not
the answer. POV-Ray needs a programming language, not a markup language.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Isn't it funny how someone like Bernd here gets a different idea and slant
on things and wants to try it - only to be spanked by other users because
it's "not practical" or "not the done thing"???
Too bad.
My advice Bernd:
You go for it.
Do your thing and don't let stuff get you down.
Nathan
By the way, I have no idea what XML or anything like that is, so I can't
help you there... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.41d623caa2588acaf1cc99770@news.povray.org> , "Captain
Chemistry" <njj### [at] studentmonasheduau> wrote:
> Isn't it funny how someone like Bernd here gets a different idea and slant
> on things and wants to try it - only to be spanked by other users because
> it's "not practical" or "not the done thing"???
>
> Too bad.
<snip>
> By the way, I have no idea what XML or anything like that is, so I can't
> help you there... :)
It you do not know what you are talking about it is usually best to remain
silent rather than post a comment offending virtually everybody else in the
discussion.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|