 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Alain <ele### [at] netscape net> wrote:
> The important thing, IMO, is that it doesn't hard-code that what is
> returned by the function is precisely a mesh. It should be more abstract
> than that.
Actually no. I would want a mesh object to be able to load from mesh
data types only (or be created on the fly in SDL like always) I would
never want a CSG union, light source, or bologna sandwich to be able to
load into a mesh, for instance.
The POVMesh object should descend from a POVObject, just like a
POVSphere, POVCylinder, POVBlob, POVUnion, etc. But there should be no
way that a POVCylinder would implement the loadfrom3DS() method.
Keep in mind that the point of this thread is not about things to do to
the SDL to improve it (which should also happen), it's about decoupling
the SDL from the back-end so that we can integrate with more powerful
languages (along with the SDL). The examples I gave were not how I
think the SDL should look at all. I was envisioning what the code would
look like in a fully object-oriented language.
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>> In order to keep current syntax spirit, I would rather propose something
>> like:
>
> The problem is that it hard-codes that the imported object is a mesh.
> (Can .obj files contain other things too, such as NURBS or whatever?)
>
No it's not associating ".obj" with meshes. if you want to import a
NURB, then you would use the POVNurb.loadfromobj("nurbfile.obj");
Maybe better for the mesh would be
POVMesh.LoadFromWavefrontObj("somefile.obj");
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> Warp wrote:
>> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>>> In order to keep current syntax spirit, I would rather propose something
>>> like:
>>
>> The problem is that it hard-codes that the imported object is a mesh.
>> (Can .obj files contain other things too, such as NURBS or whatever?)
>>
>
> No it's not associating ".obj" with meshes. if you want to import a
> NURB, then you would use the POVNurb.loadfromobj("nurbfile.obj");
>
> Maybe better for the mesh would be
> POVMesh.LoadFromWavefrontObj("somefile.obj");
>
>
I think the main problem with this approach is that you assume you
always know what is in the file. That is a dangerous assumption if you
write a library. It is also not important from a POV point of view,
whatever it is that you load, you can translate, scale and texture it,
so it is an object.
Warp's question was if .obj files can be anything apart from meshes i.e.
if it can harm if you put the result in a mesh. Technically for an .obj
file there may not be a danger, but conceptually it is wrong because
other files can contain other objects and you don't want .obj loading
routines to behave different from, say, .off files.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jérôme M. Berger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Warp wrote:
>> Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
>>> In order to keep current syntax spirit, I would rather propose something
>>> like:
>> The problem is that it hard-codes that the imported object is a mesh.
>> (Can .obj files contain other things too, such as NURBS or whatever?)
>>
> .obj files can't, but other formats can. So how about:
>
> victoria = object {
> load_file {obj "victoria.obj" [obj-specific options]}
> //load_file {3ds "zorg.3ds" [3ds-specific options]}
>
> ...
> }
>
> object { victoria }
>
> This would apply to formats that contain other object types, while
> keeping a syntax that's closer to the current one.
>
I would say that your line
victoria = object {
should be
#define victoria = object {
Or something similar, because I would like to see a difference between
defining an object that may or may not be used more than once, and
naming an object for future reference. So 'victoria = object {...'
should IMHO also create the object and not only define it as a shorthand
for later reference. (hmm, do I make myself clear?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> I think the main problem with this approach is that you assume you
> always know what is in the file. That is a dangerous assumption if you
> write a library. It is also not important from a POV point of view,
> whatever it is that you load, you can translate, scale and texture it,
> so it is an object.
> Warp's question was if .obj files can be anything apart from meshes i.e.
> if it can harm if you put the result in a mesh. Technically for an .obj
> file there may not be a danger, but conceptually it is wrong because
> other files can contain other objects and you don't want .obj loading
> routines to behave different from, say, .off files.
Typical behavior in the programming world is that when a mesh tries to
open another file, it acts the same as when you (for instance) try to
open a .wav file in paint. You would get an exception.
If there were a wavefront object file were opened by a
nurb.loadfromobj(), it would raise an exception. The filename is
irrelevant, except to make it a little easier to use the default
file-open dialogs on it.
Think of it this way: if you load an image in POV of type "jpeg" and a
filename of "MyImage.png", the parser barfs. Ditto if you did #include
"command.com".
It would be the same here - the language can't load raw SDL into a Mesh
container.
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia <209### [at] gmailcalm> wrote:
> Warp wrote:
> > Bruno Cabasson <bru### [at] alcatelaleniaspacefr> wrote:
> >> In order to keep current syntax spirit, I would rather propose something
> >> like:
> >
> > The problem is that it hard-codes that the imported object is a mesh.
> > (Can .obj files contain other things too, such as NURBS or whatever?)
> >
>
> No it's not associating ".obj" with meshes. if you want to import a
> NURB, then you would use the POVNurb.loadfromobj("nurbfile.obj");
>
> Maybe better for the mesh would be
> POVMesh.LoadFromWavefrontObj("somefile.obj");
>
>
> --
> Bryan Valencia
>
I agree that the 'load' method is specific to the type of object involved.
However, your notation does not appear to me as POV-like. For me, it would
rather be:
nurbs
{
load_file {obj "my_2cv.obj" [nurbs-specific modifiers]}
...
}
and
mesh
{
load_file {obj "victoria.obj" [mesh-specific modifiers]}
...
}
Bruno
PS: These lines would invoke internally (once compiled or while interpreted)
some methods like you say:
POVNurb.loadfromobj("my_2cv.obj"); // Or through an instance of POVNurb
class
POVMesh.loadfromobj("victoria.obj"); // Or through an instance of POVMesh
class
but internally only.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bryan Valencia wrote:
> andrel wrote:
>> I think the main problem with this approach is that you assume you
>> always know what is in the file. That is a dangerous assumption if you
>> write a library. It is also not important from a POV point of view,
>> whatever it is that you load, you can translate, scale and texture it,
>> so it is an object.
>> Warp's question was if .obj files can be anything apart from meshes
>> i.e. if it can harm if you put the result in a mesh. Technically for
>> an .obj file there may not be a danger, but conceptually it is wrong
>> because other files can contain other objects and you don't want .obj
>> loading routines to behave different from, say, .off files.
>
>
> Typical behavior in the programming world is that when a mesh tries to
> open another file, it acts the same as when you (for instance) try to
> open a .wav file in paint. You would get an exception.
>
> If there were a wavefront object file were opened by a
> nurb.loadfromobj(), it would raise an exception. The filename is
> irrelevant, except to make it a little easier to use the default
> file-open dialogs on it.
>
> Think of it this way: if you load an image in POV of type "jpeg" and a
> filename of "MyImage.png", the parser barfs. Ditto if you did #include
> "command.com".
I agree (apart from the parser barf, that is a runtime error. The
association of an extension to a format is a windows thing and POV isn't)
> It would be the same here - the language can't load raw SDL into a Mesh
> container.
and here we part ;) It may be this way if it were implemented your way,
but my point was that it shouldn't.
Please explain why the user has to know what is in a file when writing a
POV script or library.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4716501d$1@news.povray.org>, 209### [at] gmailcalm says...
> Warp wrote:
> > Alain <ele### [at] netscapenet> wrote:
> > The important thing, IMO, is that it doesn't hard-code that what is
> > returned by the function is precisely a mesh. It should be more abstrac
t
> > than that.
>
> Actually no. I would want a mesh object to be able to load from mesh
> data types only (or be created on the fly in SDL like always) I would
> never want a CSG union, light source, or bologna sandwich to be able to
> load into a mesh, for instance.
>
> The POVMesh object should descend from a POVObject, just like a
> POVSphere, POVCylinder, POVBlob, POVUnion, etc. But there should be no
> way that a POVCylinder would implement the loadfrom3DS() method.
>
> Keep in mind that the point of this thread is not about things to do to
> the SDL to improve it (which should also happen), it's about decoupling
> the SDL from the back-end so that we can integrate with more powerful
> languages (along with the SDL). The examples I gave were not how I
> think the SDL should look at all. I was envisioning what the code would
> look like in a fully object-oriented language.
>
It might be noted that there are some mesh formats that contain some
additional data, some/all of which "might" be usable as well, so the
result would need to either include commands to "load" those elements
using other commands (which may/may not be a good idea), or import them
at the same time. I.e. the "mesh object" generated would need to also
include those things, like textures, etc., when completed. Obviously
those things need to be accessible later too, in case, for example, you
don't want to use the texture that came with the model. But otherwise,
yes. It wouldn't make much sense for something like "cylinder" to have a
"cylinder.loadfrom3DS" function. In fact, it makes a lot of sense to
only apply the imports for certain types "too" the types that support
them. So, in the case of mesh, you make an empty mesh, then use "its"
import function to get the result.
Mind you this won't work for something like a AutoCAD files, since it
can contain a mess of different data types, not just meshes, so you also
need a sort of "importobjects" function that can generate a table of
objects from the file. You don't one, in that case, a single object,
like some of those horrible converters I tried way back when did, where
it took dozens of distinct objects, like from a CAD file of a human
body, and generated "one" mesh, when the original file had them clearly
subdivided into individual parts. What a mess that was...
--
void main () {
call functional_code()
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just to digress a bit, anyone used Eclipse plugin framework before?
I was reading about this game called codeinvader.
[www.alphaworks.ibm.com/tech/codeinvaders]
To start using, i need to dump 2 files into eclipse plugin folder. And
magic, I can use eclipse to start editing for codeinvaders...
why do we need POVSphere that is inherited from POVObject?
The idea is that developers can write plugin, and to interface it
Library{
"name of plugin", "function name", para1, para2, ...
return: ret1, ret2,...
}
in terms of loading data like 3ds or meshes, the above plugin library will
allow programmers to code for it.
I find using import(3ds file) weird, it looks like functional programming,
yet OO at the same time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
zeroin23 wrote:
> why do we need POVSphere that is inherited from POVObject?
We don't really from a language standpoint, but if you (like me) want to
write a truly OO language then it would be truly useful.
> The idea is that developers can write plugin, and to interface it
> Library{
> "name of plugin", "function name", para1, para2, ...
> return: ret1, ret2,...
> }
It would be more efficient to use an OO language to send stuff directly
to the rendering engine rather than translate it all to SDL and then
parse it back to objects again 0.001 seconds later. You have to know
that once POV parses your script, it is somehow becoming OO in the
bowels of the renderer.
> in terms of loading data like 3ds or meshes, the above plugin library will
> allow programmers to code for it.
That's cool but I want more. I want to monkey with POV's brains! Mwahahaha!
--
Bryan Valencia
"I'd rather live with false hope than with false despair."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
