Making money with an opensource effort, lets be straight..

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

cgul
Posts: 0
Joined: Fri Apr 11, 2003 12:10 am

Post by cgul » Mon Jun 02, 2003 6:27 pm

Hehehe, This is fun.

I don't know anything of the historical politics, individual motivations, or any fears that people possess. All I know is that the future of Blender will be guided by what is available to it for inclusion and adoption, and to some extent a "visionary plan" to guide some of the developers.

Do you think that a journalling file system would have been included in linux if some "maverick" out there decided that s/he felt like making one, then linus saw that it was good and sucked it in.

Anyway, my point is that it is my belief that we should embrace any and all efforts of individuals or groups to play with the code or build something that may or may not be related to blender. Some people will play with it, the chief code monkey (is that ton?) will then listen to his possee of code monkeys, to the general population, and to his internal monologue and then decide if it should be included.

People will then complain, and some will cheer! At some point in the future, some will fork and run and label themselves purists, some will forge ahead in another direction. One of the branches will wither, or both will grow.

The future will be bright and shiney....(heck maybe even ray traced)

Basically my point is let people fly AND build a plan so that we can apeal to all types of coders and have a richer selection of things to choose from in the future. Who knows, maybe this verse thing will turn out to be an excellent way to create an amazing UNDO function, and never turn into anything more than that! But we would never know if we shut someone down spiritually!

Cheers
cgul

Jamesk
Posts: 239
Joined: Mon Oct 14, 2002 8:15 am
Location: Sweden

Post by Jamesk » Mon Jun 02, 2003 7:30 pm

xype wrote:Ton goes mad, tells Eskil to rewrite Blender with a interactive-boobie-fumbling UI - - -
Heh, that would be a lot of fun! :lol:
Maybe I've simply overestimated the future impact of Eskil's design theories. My apologies. He hasn't commented on these posts himself yet, though.

dreamerv3
Posts: 119
Joined: Wed Oct 16, 2002 10:30 am

Post by dreamerv3 » Tue Jun 03, 2003 1:48 am

Oh... So it was Eskil, who was being referred to...

I think Verse is important in the sense that network connectivity is important, and I'm not saying it won;t work or that people shouldn't develop for it. (who would listen anyway, this IS opensource after all)

My biggest argument is: Make it modular and make a common interface to functions in the libs, quite possibly I would love to see a blender kernel powering different software projects which use it, just as mozillas' GECKO rendering engine powered mutliple apps.
something like:

!! You must have thecore blender installation with kernel version x.xx installed in order to run (forked project X)!!

That would rock, it would all be one big family...

The blender family of apps.

That sounds cool...

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax » Tue Jun 03, 2003 12:41 pm

Well I guess it should be possible to break the rules every now and then.. But the free-spirit mentality usually doens't work so much, I mean
if the coders are not acting on concert, what chances are they writing over the other's code without a complete idea of the other's contribution
effort? The way it is now there is relatively few coders, I believe, because they don't seem to be conflicting in the features that are added..
Its possible they could be talking to each other via Instant MEssenger
to notify each of a conflict int eh codebase.. The CVS will tell them..
But there is no way to determine a semantic conflict, say in an assumption about a state variable or a data type..

Having a clear design goal with docs is like knowing whose toes not to step on.. Its easy to have a lot of confidence in individuals but this source is huge and features I've seen being added are minor ones here and there.. There are major changes that need to be made, like the
way polygons are structured from the bottom up to support winged edges.. Vertices for polygons, lattices, surfaces, etc. Need to be the same.. RGB sliders need to have alternate HSV sliders.. Rotations
need to use Querternions (not really familiar with them but recall
they help consistent rotations without some of the probelms found in blender).. Etc.. If you can collect enough related problems, ther eis a
chance there is a single fix that can be done and another chance that a structure can be determined to allow all the problems to be fixed..

Now did I say Eskil would cause LoqAriou to be blender's interface, it was so rudimentary it looked like a design concept than a real interface..
I mean he used basic draw functions and alpha-blended polygons and neeto-wizo effects to make things look cool, but I have yet to see anything modelled with it.. It kept crashing on me, and the mouse buttons were unified in a odd-way that didn't make anything easier.. It looked
like an approach at doing a special surface type (influenced by Maya?)
and allowing objects to be created quickly with just a mouse.. But its extremely hard for even Eskil to make stuff with it..

Now Verse is a nice idea, its just that it could be broken up a littl, made into a standard for interchange of objects and a standard for shared
memory and interaction between client/server .. Also sometimes coders will talk to users like saying Jargon will wow people.. Its not wowing me,
my question is where is it going.. If you talk generally about the future,
is that so easy? Is it enthusiasm or is it hype? It felt like I was
being advertised to and it reminded me of marketing campaigns
to developers, as are common in copies of Dr. Dobbs journal..
Now Eskil brought about the idea of breaking blender down into
interacting objects.. That's okay, its still questionable
why one would want to do that.. Is it just to see that it can be done?

By making a package into a bunch of pieces and interconnecting them,
how is that any different from one package.. Until I see a design plan
it looks like a silver bullet for some undefined use.. Does he give
use-cases or examples of using Verse, or is it speculative
a byproduct of the interactive shared memory design?

It just is too vague, protocol or not..

Anyhow, I'm already starting the design process.. I had said elsewhere
(the functionality board" topic) that I will be goin through the
source and producing a UML document of some sort to match
modules to classes (blender is not object oriented, so a UML design doesn't work well to detail it but I think I can make something close
that could be reworked)..


What I need of the users is to have them go through blender's
interface and recognizer similar features, and features that
should exist elsewhere, with the purpose of classifyin functionality
which will imply some of the more easily identifiable Objects.
This is called Object analysis, we look into the design and determine
what things are related.. This will help us to understand what things are
acting like objects and what are not (implying a discontinuity in the
underlying sources).. For instance the interface to the
colorbands and vertex paint interfaces uses RGB sliders
but there is no HSV option, so obviously there is some duplicatoion of functionality there..

cgul
Posts: 0
Joined: Fri Apr 11, 2003 12:10 am

Post by cgul » Tue Jun 03, 2003 4:19 pm

Thorax. I look foward to seeing some of the UML you are going to create. I am still just barely dipping my big toe into the source in preparation for a swim.

I hope to be able to use my "this doesn't look right" skills to help with the code a bit.

Good luck with your effort and post often with your updates.

Cheers
cgul

IngieBee
Posts: 111
Joined: Sun Oct 13, 2002 8:26 pm
Contact:

Post by IngieBee » Tue Jun 03, 2003 5:04 pm

xype wrote:Oh. My. God.

First, NGB is not trying to hijack anything. Is it _that_ hard to understand that VERSE IS A PROTOCOL. ... cut ...

... how can you say it has nothing to do with Blender? Wouldn't you want Blender to have an interface that people can code against without having to "hack" the main Blender code? Wouldn't you want Blender to get networking support, both for eventual realtime 3D as well as 3D animation creation? .....
If only I knew how to "speak"... You say it quite eloquently here. Yes, it’s a project totally independent from Loq Airou, Quel Solaar or any other project Eskil has done. Yet, one would be able to use such programs with this protocol and interact with someone/thing using “Blender” on the other side. It’s only a foundation for new possibilities. If it opens up doors for people to sell “attachment” programs that offer things not otherwise available in Blender, all the better. It’s not like everything has to be open source. It’s not immoral to sell your work, after all. If Eskil has ideas for opening markets this way, that would be cool. But remember, what Eskil has given to us is open sourced, so we can all enjoy the fruits of his labor.

Shoot, this thing… NGB … isn’t even being used yet. Wait until you see people implementing things with it. I hope someone who can code is playing with it now, ‘cause if I could, I would.

But you see, when I think too hard, my head starts to hurt, and I’m in danger of falling asleep………. :lol:

(yawn) g'nite.... oh... wait... I'm at work,, I better get some more coffee....

Love ya all, just don't freak out please :P Ingie

dreamerv3
Posts: 119
Joined: Wed Oct 16, 2002 10:30 am

Post by dreamerv3 » Tue Jun 03, 2003 9:05 pm

making visual daigrams of the dependancies inside the source is a good idea.

I too am going to try to understand what could be consolidated into objects.

The Docboard has a lot of information already.

thorax
Posts: 320
Joined: Sun Oct 27, 2002 6:45 am
Contact:

Post by thorax » Wed Jun 04, 2003 7:51 am

Shoot, this thing… NGB … isn’t even being used yet. Wait until you see people implementing things with it. I hope someone who can code is playing with it now, ‘cause if I could, I would.

But you see, when I think too hard, my head starts to hurt, and I’m in danger of falling asleep………. :lol:

(yawn) g'nite.... oh... wait... I'm at work,, I better get some more coffee....

Love ya all, just don't freak out please :P Ingie
Well there is not much magic in coding stuff up, its very structured
whereas in art you can be free to do a lot of stuff, in coding there
is only a certain amount of freedoms you can take because you
work within the constraints of efficiency.. You have to be creative
with how you balance out commands in order to be efficient..
Its better to be a math major because you can make optimizations
in the way things are computed.. Usually one must consider the
use of the code to determine how to optimize it, like with mp3 compression you do a FFT on a sound, and rip out the frequencies that
a human can't hear or are least important and store the most frequencies for a limited number of bytes of bandwidth, balancing quality with
the constraints of the bandwidth limitation.

Anyhow
My take is that Verse doesn't use shared memory (although it wouldn't be hard to add it), it was designed to distribute information among multiple programs using UDP packets (the same packets used to update the state of multiplayer videogames like Quake).. So another purpose of Verse
could be to allow it to act like a video game server..

Client and servers are arranged in spoke-hub model, and he claims it
will scalle by making the servers with client interfaces that connect to
other servers.. But its not true peer2peer because the clients
are not assumed to be servers always.. The clients can subscribe to
data created at the server, so when one client creates new information,
it can be sent to the server and all clients that subscribed to that model will receive the model..

The UDP packets also are provne to being lost so there are parts of verse for handling how much care should be taken on lost UDP packets,
and so there are distinctions in commands that are sent based on
their value to a operation, like some commands can be sent only once (and are not valuable if they are not received on the other end),
some commands are order dependent (so the client and server
must maintain history buffers to buffer packets received before a
command can be executed, this is like receiving binaries over Usenet,
if one package is missing the whole package is thrown away and
the information has to be resent.. Also packets can contain multiple
commands, but each packet can contain only about 500 bytes..
The commands are byte encoded (short and sweet), data id's are
scoped to the client , so a client can't refer to another client's object without using the name of the object.. But Eskil could have also
allowed clients to address each other's objects using their addresses
to define the domain of the ID, and the server knows of the other clients
so it could arrange the connections between the clients producing a semi-p2p relationship..

Now this is the kind of thinking that a pre-design session
would have benefitted us, but I'm sure when Eskil sees this
he will probably go on a massive code rewrite and add
addresses to the ids, make the ids the size of the data names,
and make a seperate name for the packet.

Note Eskil, you only need something like a 128 bit id,
then a 32 bit address, and in your server you could use a xreference
table to determine the particular object referenced on the server,
and the client can use the object with this id without having to make
it a part of its own ID domain.. Also the client's can refer to each other's
objects in the same way, so rather than having to maintain overlaping
id domains for each object that is shared, all the clients can refer
to the same object by using the domain it was created in to
reference it.. The client then only has to distinguish between
getting the object that exists within it from the object that
is located elsewhere.. And at least it can refence the domain that
created it to get the object, because the object ID is 128 bit number as
the IP address.. There should also be a replicant number that determines
the number of copies that were made of the object, or
maybe a data on the object to determine when it was made to determine
if the object is out of date..

I think I will go and give this tip to Eskil in his message on Verse..

I still think true objects should be implemented so that Verse can allow
for bots and mobile agents.. The guaranteed unique ID's are needed if Verse is to scale to a true P2P model with bots and mobile agents (a mobile agent can only be recognized by giving it a large random number and a domain id {IP address})..

Post Reply