r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Extensions] REBOL 3 Extensions discussions

Maxim
18-Sep-2009
[153x5]
not now, but it will when the image! datatype is supported (in next 
extensions update).  This is the easiest way to integrate image applications 
into rebol, but also the slowest.
for video, I'm not sure... it would have to use callbacks, cause 
the synchronisations and refresh stuff is so complicated.  But maybe 
we could be able to open up ActiveX or other supported OS controls 
which can render directly within window rasters, as long as the host 
code knows how to link them into their windows.
so some changes in the view engine would have to be done for FMV 
to be added natively in its windows AFAIK.
horde doesn't offer all of what I need for the quality.
I'm also thinking that I could build a flat C SDK for Ogre which 
would make its integration into R3 much simpler after... basically 
storing stucts and pointers to things internally and using a few 
simple and fast generic scene query calls.
Janko
18-Sep-2009
[158]
yes, ogre is really "topnothch" .. maybe you could reuse, maybe the 
ones who made python/lua/... bindings already made a c overlay
Maxim
18-Sep-2009
[159x2]
ah good idea.. will see their approach as a reference for mine.
so far, the way I understand it, its possible that callbacks aren't 
necessary for Ogre.  Not for simple scene creation and interaction 
AFAICT.
Janko
18-Sep-2009
[161x2]
there are at least python / java / .NET / lua bindings that I am 
aware of .. making something like python-ogre for rebol would be 
awesome
but also quite a task .. maybe you could geenrate rebol binding or 
part of it from some othe binding programatically .. I know some 
folks did something like that for GTK / WxWidgets from haskell to 
ocaml
Maxim
18-Sep-2009
[163x2]
and the actuall download isn't insane... it ~45MB.  for a full-featured 
cutting-edge 3D engine this is very small.  We have to remember that 
3D and image aren't just functions, they actually require data which, 
because of the array aspect of them, requires a lot of memory... 
so I am thinking that a large part of the 45MB is in fact source 
data which is needed, in order to populate the actual scene.
yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.
Janko
18-Sep-2009
[165]
very cool, as I said this is not a minor task but if you do it it 
will be very awesome!
Maxim
18-Sep-2009
[166]
I Will, I need it  :-)
Janko
18-Sep-2009
[167]
what will you be making?
Maxim
18-Sep-2009
[168x3]
ElixirOS and some other commercial stuff which needs serious scalable 
views rendering tens of thousands of objects in real-time.
the first piece of the cake is building GLASS with whatever 3D engine 
I can extension.
GLASS is a general purpose GUI using advanced dataflow programming 
at its core.  I've got some prototypes of various pieces of GLASS 
using R2 and AGG which work really well, but I've been waiting to 
be able to do HW gfx before Investing time on the real GLASS, which 
integrates the prototypes and new stuff too.
NickA
19-Sep-2009
[171x3]
I
Max
(Oops).  Max, I experimented with OGRE in Purebasic a few years ago. 
 Frederic Laboureur built a very nice interface to it, which comes 
built in native to Purebasic.  He'd likely be a good person to chat 
with, and he's very active on the purebasic forums...
Maxim
20-Sep-2009
[174x3]
noted  :-)  I'm starting to really look into this right now... taking 
a break from my "serious" programming.
will start by playing around with the C++ stuff, basically building 
a simple scene.... when that is working, I'll try to build an extension, 
allowing me to do the same calls via R3
btw, some of the picks from apps make with Ogre are damned beautifull!
Pekr
20-Sep-2009
[177]
what is so special about the Ogre? Just a 3D engine, no? Is it used 
mostly for games? What would you use it for?
Maxim
20-Sep-2009
[178x5]
programming for a 3D rendering engine and for a scene engine is a 
totally different affaire... just like using DRAW vs using AGG directly.
Ogre is probably the most complete open source scene engine, which 
can use both OpenGL and DirectX.
its a complete hardware abstraction, so the exact same code will 
run under any hardware/OS implementation.
This layer handles all of the nasties for complex math like shadows 
and even some of the SW & HW shader/texture manipulations at a higher-level.
but since its all open source, you can fix specific issues or optimise 
parts of the engine to suit your needs, if you really have to.
Pekr
20-Sep-2009
[183x2]
so Ogre is in 3D kind of what AGG is for use in 2D - an cross platform 
abstraction?
use=us
Maxim
20-Sep-2009
[185x5]
yes.
and its VERY clean.  Its EXTREMELY documented and there are many 
FANTASTIC plugings from all sorts of authors.   (using apple type 
marketing hype here ;-)
and next version will be MIT which means total licensing freedom.
just the fact that you can retarget the whole 3D engine to direct 
X, OpenGL (or another if you wanted to do so) is really impressive.
I guess this comes with some visual difference, but it means you 
can make it as optimised as you need it depending on platform.
Pekr
20-Sep-2009
[190x2]
I wonder how well does REBOL work with such kind of stuff. What will 
you use? Kind of direct linking to functions? Or kind of dialect 
abstraction as we use for AGG (draw)?
What is the best method to hold data/config to external systems and 
their data structure? Is that an object? Or utypes? :-)
Maxim
20-Sep-2009
[192x5]
both, scene creation will be dialect based, with a full mapping of 
EVERY single public class, member & method
utypes would allow us to abstract the interface, so that would be 
my preference.  

otherwise I usually use objects or nested blocks for complex structures.
above: "with a full mapping"  I meant that  "there will *also* be 
a full mapping"
with vector support this will make it very fast to xfer data between 
3D apps & rebol, since the data will be usable AS-IS in both directions 
 :-)
which always part of the point of implementing vectors AFAIK.
Pekr
20-Sep-2009
[197]
do we have multidimensional vectors?
Maxim
20-Sep-2009
[198]
I don't remember... Not in the first releas IIRC
Pavel
22-Sep-2009
[199]
Probably to BrianH: is it possible to open file in Rebol and transfer 
the filehandle to extension C routine? Or is it neccessry to give 
the filename as parameter and reopen in extension subroutine?
Pekr
22-Sep-2009
[200]
I forwarded the question to R3 Chat IIRC, but no reply. We will see, 
once we get back to the Extensions topic. Now there are some big 
changes to 'parse happening, so I would probably not disturb Carl 
with additional questions :-)
Pavel
22-Sep-2009
[201x2]
Is it even possible to unload extension? IE where and when RX_Quit 
comes into action?
Practically when you want to restart/exchande extension you have 
to close whole rebol process.