A couple little hopefully clarifying points:
I think what Peter meant with porting and Jonne with rewriting is the same
thing.. taking ideas and implementing them on Tundra, i.e. porting to Tundra.
Possibly abstract logic code could be reused within some functionality, for
example in a camera animation math code or game AI logic rules or so. Benefits
of Tundra being reportedly nicer arch and code structure, ECs vs. using
inheritance hierarchies for the functionalities etc .. the core mechanics on
which the features would be rewritten. It sure is encouraging and nice that an
outside evaluator who has studied sources of both softwares makes that proposal
About reX scope Tundra Core etc: certainly we are not changing the definition
of Tundra core, fancy editors and asset libraries etc. are definitely not part
of the core (as in the core APIs, ‘the purple box’, the non-optional parts of
Tundra SDK) and at least if they are large or custom, not part of the SDK and
the default distribution either.
In an extreme case, if we’d decide to pursue a complex e.g. a
one-click-app-creator within realXtend, it could well be e.g. a separate
project with an own repo and all .. for example an optional Tundra plugin which
could be bundled in some ‘creator release’, but which would not be necessary in
a minimal end user client used to visit scenes. A port of Ogitor to be a Tundra
plugin would certainly fit in this category I think, as a fork tracking the
original Ogitor repo perhaps.
I just want to keep it clear how realXtend assoc. activities and Tundra core
SDK scope can be different things, it is up to us to decide where we think
cooperation and some common public effort would be most useful.
That said, in the meeting I found that shaders were one concrete
content-centric topic which seems nice and simple, and which can help almost
everyone to create more things easier. The current SuperShader and other
bundled shaders for e.g. the parallel split shadows etc. are in all releases,
are basically always assumed to be there, is ‘core’ in that sense (whereas
technically they are more just arbitrary scene content) -- if there are clear
needs for improvement in that department it could make a nice little project.
Of course they don’t help anything alone, if no one knows how to create a new
scene or app, but as one piece for the puzzle. One relieving point about
shaders is that they are at least somewhat engine agnostic, AFAIK same GLSL can
run in Ogre and WebGL and whatever other engine (well, at least when using
opengl.. but that’s a different discussion).
I’d like the creation focused track to continue as planned, with Ludo and
Spinningwire/ENER etc. art folks gathering requirements for their professional
work etc., and Admino informing about your needs. BTW Jonne it was originally
Tommi from Admino who said that new content examples and something to help
content creation would be the most important thing for reX now
But definitely docs and tutorials etc. are so important, obviously related to
ease of creation too, that must be top priority. I don’t know yet how to
organize that work but I think will talk with Kari, perhaps he has ideas how to
get some funded doc project going. Last year I tried to get some university
folks at the dept. of information processing sciences (software engineering
etc) who work with people in the informatics department (library etc folks on
the humanist side) to do some reX document work but haven’t heard anything
back. Perhaps useful for long term, but for a quick fix we need something
simpler .. a little project for some company and/or just doing more tutos and
docs in our free time.
~Toni
From: Jonne Nauha
Sent: January 9, 2013 11:11 PM
To: realxtend@googlegroups.com
Subject: Re: [realXtend] reX assoc board meet: focus on creation tools
you point to code/sceenshots to get some kind of idea? I doubt there is any
porting to be done, its a completely different beast without all of our
dependencies/libraries/frameworks. Features/ideas can be copied (if they apply
to the Tundra idelogy) but they will probably need to be rewritten from
scratch.
I think we can however agree rex project should focus on documentation and
examples (both c++ and javascript). Content creation tools can also be on the
table, but as we have talked numerous times (in the issue tracker) Peter it
might not be in the Tundra SDK scope to have fancy editors and ship certain
kinds of 3D assets with it. Maybe we need to adjust that purity goal, I don't
know. I would like to see the assets at least in a different repo if this
happens and move /bin/scenes and parts of /bin/media there too.
I think many of the end user problems with Tundra come from that we are a very
programmer oriented thing. You can't do much with Tundra if you don't know how
to code or are willing to look at some headers. This can partly be solved with
