Page 2 of 2
REasons for blender and not scratch
Posted: Wed Mar 23, 2005 9:27 pm
Here were my reasons for Blender and not starting from scratch:
Blender has documentation, already made tools, and a set-up for plugins, since a large part of the open-source world and some commercial people use Blender, we want to keep it as close as possible - the program shouldn't know it isn't blender. Keep it 100 natively compatible with the blender formats, plugins, only extend the program to farther than blender is because it's Focus isn't modelling but editing models, skinning them, texturing them, placing them, and scripting them.
Blender is already cross-platform and suits the nature of what tools I want to use and how I want it to work. Also, the gameblender folks need new engine for gameblender anyway, and the only way I see it working is by seperating the two. This might be an official blender project someday.
Also, you mistook what i said about the interface. Evening is based on the code-base, not on the interface. The interface will be a completely different (same themes) sturcture. It has to be - this is not a modelling program but a scene editor. The focus is different, diferent capabilities. You wouldn't make open-office look like the GIMP, because open-office is a word processor not an image manipulation program. Evening and Blender will be the same way.
Posted: Thu Mar 24, 2005 12:48 am
IMHO, its API can't be called clean in comparison what else there is out there which for me makes the burden harder than what I'm gaining.
Anyway, It's a different concept. Personally, I don't care about modelling and skinning tools etc in a scene
editor. I prefer to keep a tight focus on succeeding where existing (mostly free) tools in terms of usability and features and interoperability fail. So I guess, we actually have different things in my mind.
Still, maybe there's room for some joint effort
Btw, as you mentioned GIMP... you noticed that it looks more and more like Photoshop with each release? Guess why?
Posted: Thu Mar 24, 2005 8:52 am
OT: How does the Gimp resemble Photoshop in any way? It certainly looks/acts very differently, and I haven't noticed anything making it look similar. The recent changes are new GTK2 functionality...(not unique to adobe products)
GIMP and Photoshop?
Posted: Thu Mar 24, 2005 9:20 pm
The GIMP does not look more and more like photoshop with each release, but rather as two seperate photomanipulation suites embrace the same features they are both aiming towards a common goal, it only makes sense that both will somewhat resemble the best shot at that goal in the time that they were made in.
The GIMP has one feature though: customizeability. You can make GIMP look like PS or PSP or whatever. The dialogs and windows can be moved around and rearranged however you like. The only thing (and one that originally I wanted most, but not anymore) was a parent window. But, even PS is following the GIMP into the seperate window world (because it is a better model for multi-tasking)
I think we really need to forget that whole thing of X is ripping Y off, only because Y is the most popular example of a number of programs reaching towards one goal. That's actually quite ignorant, saying that only one program is innovating or progressing (sometimes the case, but almost always not fully true, most programs may adopt a common goal or feel of a popular one, but still continue to progress and evolve in a slightly different way on their own)
Posted: Thu Mar 24, 2005 9:44 pm
Such things aren't necessarily about innovation. For example, take a look at OOo and compare it to MS Office. You can start to work right away. Why is that? Because the interface and the workflow is nearly identical (with minor exceptions, of course). That's a good thing as it makes transitioning in either direction easy.
And I'm not saying ripping off is a bad thing, either
If a specific feature or a specific combination of features is implemented well, then that can be inspiring (either resulting in a rip-off in which case it fulfills the its purpose or maybe even an improvement, the latter is obviously desirable).
While we're at "stopping"... let's stop bashing the different sides. Open source, closed source, proprietary software and all these things can
live together and in most cases there are very valid reasons for using one or the other or a certain combination. Let's make the best of it (and not use GPL
We still have a chance to return to the topic. I found it interesting. But maybe people find the direction this is currently heading more appealing...
Posted: Fri Mar 25, 2005 12:59 am
I actually thought about this idea of Blender + OGRE toolkit as well a while ago, but after reevaluating it, I can see it having some problems. Walk with me for a moment:
If one looks at Garage Game's Torque engine (or the new shader engine coming out for example), one of the strongest selling points of this whole package is the phenomenal development toolkit that is available, from start to finish, you are working within highly productive, Torque centric tools (I've heard). Couple this with documentation, and active user support, and you have a very strong package that any developer wouldn't think too hard about jumping into.
Now my idea was simply to just emulate this behavior for Ogre in the 'Blender + OGRE Toolkit' but then I saw some key issues: Torque is an entire game engine whereas OGRE is a rendering engine, pure and simple. And the problem with a Blender toolkit would lie within the fact that: Well, now that you have your scene made in blender, you want to apply a certain sound effect to this object, or perhaps simulate this object with a physics primitive. But we are straying from the graphics abilities of OGRE, and this OGRE + Blender toolkit would either be lacking in complete functionality, or would contain hacks in order to get it working with outside libraries in respect to other game aspects.
Therefore each toolkit would have to be specific to the exact game framework/makeup. This is more in line with what happens now with everyone making their own specific little toolsets/processes to get from point 0 to point Finished.
Perhaps this is why I liked the idea of Chronos (or perhaps it was what was planned in Chronos 2) is the idea of plugins that would allow for you to add this functionality in a nice clean manner (that others can then take and run with). So you could effectively make your own toolkit by adding/subtracting plugins.
Posted: Fri Mar 25, 2005 3:22 am
@bana: Maybe one of us is lucky and achieves to create a clean plugin API for exactly this purpose!
Or just wait, hehe!
Posted: Fri Mar 25, 2005 7:13 am
psy: Yes I was actually thinking about Yake through the entire post, I don't know why I didn't mention it though
I'd like to get myself oriented a bit more before I start on something completely new. Besides, OpenFrag is really needing help at the moment (the project I work on) and I want to see that go somewhere.