Blender vs K-3D vs Equinox 3D

[farsthary]

Hi all!

Well, surfing in the web i found two programs that are like blender, also GNU, but with MORE ROBUST arquitecture and future proof design, Its true that actualy they implement less features than blender has, but they are a pleasure to extend on. K-3D for example seems to me more like HOUDINI, WOW!!!
They are more extensible than blender, more flexible, especially K-3D
I am concern because I like to see that arquitecture in blender itself, not two GNU programs competing among them.

Fully procedural aquitecture, unlimited undo/ redo trees, multiple undo/redo trees (WOW!), node oriented, I could not imagine wat they are capable if they have the same blender support comunity, but I think is a matter of time.

I want that in my beloved blender because I dont want to spent time in mastering a soft that in a near future will have to be rewrite, and so on, They seems to me a better future investment.

[Caronte]

Don't offense, but Blender stay to light years of K-3D

[LetterRip]

Feel free to use whatever software you like, but it will probably be many (8? 10?) before any of those listed programs catch up to the current state of Blender.

Also the claim that they are 'better architected' seems rather questionable, I suspect that you haven't the knowledge or skill to make such an evaluation.

As to 'more extendable' you have source and there is a scripting language, so they are roughly equally 'extensible'.

LetterRip

[farsthary]

Thank you for answer me soon, but I dont get it
Years ahead or behind? Also the subject is not the current features both have, of course blender is the winner, but the more stable and extensible core design of k3d and other 3d GNU softs.

Dont fire me please, I love blender as much as you do, I only want the best for it, its true that I dont have to much know of the internal core of blender, but I do read post complainng about current blender code, and future plans for a core revamp, I also consider that such a revamp should not wait more longer because the bigger blender gets, the difficult became to change it, and a developer of feature X dont want to implement it in blender 2.4x and have to modify it for the new core blender 3.x (for example), also life could be eassier if everithing in blender could be implemented as a plugin.

Thank you in advance

[oin]

Extensible or not, that would be a too simplistic argument. Extensible is if people extend it, lol. Sorry, bad joke.

No, seriously. Been some years, but I have never been a diehard fan of blender, like with haven't with almost any tool...And I have used in depth many modelers out there. I gave a very fair chance to K3d in several occassions. Sorry, but in this comparison you bring to the table, I am quite convinced Blender's UI is quite faster(so, not talking of features). I never was big fan of the turntable/trackball options, but still, is one of the fastest UIs out there. I think there should be needed many changes in those tools to have that speed. There are few tools with this speed of use; to me, it's Wings, Blender, probably old Metasequoia.

About extending, if i did bet on the learning of Blender, which was not easy for all other UIs are different (while among them are very similar) , is because, I knew it was the one with most solid future in my opinion. And now that sensation has increased very drastically.

Equinox last time I checked was kind of curve modeler, quite featured in that, but doing exactly that. And was shareware by then...

[LetterRip]

Most complaints about the code are from people who have read 'C for dummies' or taken 'Intro to C programming' and have never worked on software of any size or complexity and are expecting code that is as trivial to understand (and is as trivially documented) as code encountered in such introductory material.

That isn't to say that Blender couldn't be better architected or better documented, but for the most part it is comparable or better than other software of its scope and complexity.

Blender gets rearchitected on an as needed basis, ie Aligorith is overhauling some of the animation code; Ton is overhauling the event system and interface related code; BMesh will probably eventually replace much of the mesh modeling code.

Projects that foolishly try the 'rewrite everything' approach generally end up halting all development and fading to obscurity.

LetterRip

[oin]

Indeed, I suspect Max has certain old code structures of which it's more slave, and still, keeps growing -despite the critics- with every need of the big studios,(the amount of powerful thing you can do with it today is crazy, as with any tool, if provided good hands) and probably will merge into a very new thing soon. Wings3d was always been criticized bout the erlang base, and Bmesh is pretty similar to many of the operations in modeling wings has since start. (not a pun here, really happy to have also that power in Blender,tho will keep modeling in the other)

When I look to tools in the same ball game than Blender: general (not specialized) 3d packages, I see no competition, neither in the future, both in free or midcost field.(nor some of the high prices either) .And I tell you I am not a fanboy

[Stukfruit]

I do have quite a bit of programming experience (close to 10 years by now, C, C++, etc. and everything that goes along with it) and to be honest, the author of this topic is partly right. The code in K3D is more extensible and it's a joy to use compared to the code in Blender.

There's even a way to write your own graphical interface for it, without the need to rewrite the rest of the program as well. I have once tried to do that for Blender.. well, trust me.. everything (data structures, screens, spaces) is so closely connected that it's nearly impossible to use something else for the gui. It would basically mean that you would have to write a complete new application from the ground up, which could use some of Blender's libraries, but that's not really worth it because the largest part of Blender's code is in the interface. The rest could mostly be replaced with alternatives (if you're using C++ that would be easy as pi, with ready to use libraries like the STL, Boost and so on).

I know this because I tried to make a comparable interface using Qt. I did succeed at integrating the spaces within OpenGL views from Qt, and I also succeeded in taking down the whole multi-window management of Blender, but hell.. you really don't want to take it even further than that. Ripping down all hardcoded shortcuts was really hell and is still not finished. It won't get finished either because it's quite a job to keep things in line and stubbed nicely with the latest svn version of Blender (as ton already noted at the sunday meeting for his own tool-refactor).

K3D on the other hand, makes it far more easy to do something like that. You can plug in any gui toolkit. Altough it sounds more simple than it really is in practice, it does prove how the code of Blender is less extensible in one of many ways, and how K3D's code is much more future proof.

I've got experience with that as well. It took me two days to get a very basic K3D interface using Qt up and running, compared to the two months it took for Blender, with less functionality.

Having that said though, the authors of K3D definitely know how to build great code that holds up in the future, but they don't seem to know very well how to build a usable interface around that great code. In that respect, Blender is more future proof.

Oh, how much would I dream about K3D with the interface and a number of other inner workings from Blender... that would be close to nirvana, I guess.

[NielsBlender]

@Stukfruit:

If you asked me; 'All' Blender needs is an OS providing basic lowlevel stuff for 'memory-, disk-, input-, outputmanagement', the only not so standard to a basic-OS would be the need to support openGL...

I don't see a 'historical/future'-mistake decision therein.

Niels

[Stukfruit]

@Stukfruit:

If you asked me; 'All' Blender needs is an OS providing basic lowlevel stuff for 'memory-, disk-, input-, outputmanagement', the only not so standard to a basic-OS would be the need to support openGL...

I don't see a 'historical/future'-mistake decision therein.

Well you know, it's not "what Blender needs to run on" what's bothering some people here.

It's the fact that Blender just isn't very good at making use of new technologies without rebuilding parts (or more) of the core code. That's no basic low level stuff we're talking about, that's all high(er) level stuff.

Look at the integration of the sculpting mode, for example. When I saw how that got integrated (no offense to Nicholas, there's no other way to do it), I nearly freaked out! It's all a giant spaghetti instead of nicely separated code that can be added, removed or extended at will.

I hope that explains it a bit better.


ps. The new animation refactor, the tool-refactor and other refactors are definitely a way into the right direction though, no bad words about that.

[NielsBlender]

Well you know, it's not "what Blender needs to run on" what's bothering some people here

Yes, I know, you've edited it out of your post I see.

It's the fact that Blender just isn't very good at making use of new technologies without rebuilding parts (or more) of the core code.

They have that same problem with hardware...

That's no basic low level stuff we're talking about, that's all high(er) level stuff.

According to your words it is...

Look at the integration of the sculpting mode, for example. When I saw how that got integrated (no offense to Nicholas, there's no other way to do it), I nearly freaked out! It's all a giant spaghetti instead of nicely separated code that can be added, removed or extended at will.

The sculptmode is or is not implemented, than there 'is implemented well' or 'isn't implemented well'...

I hope that explains it a bit better.

[Stukfruit]

Yes, I know, you've edited it out of your post I see.

Don't be so suspicious man I haven't removed anything. Just added two things to my previous post: the two parts about what I've tried to do with bloth Blender and K3D

Was just trying to make clear why one should take my words as real deal information or nonsense. I though it would be good to provide some info on the work that made me say: "hey, the current code of Blender is not future proof".

I was guessing that information from someone who actually tried to improve things (and spend many months of work at that) would be more useful than that of someone who just recently started with "programming for dummies".

The sculptmode is or is not implemented, than there 'is implemented well' or 'isn't implemented well'...

Yep, and with the current code base it's not easy to make such editing modes well implemented. Same goes for the recent particle mode by the way. It works, but you can't keep doing that (that's my vision at least).

It's just.. well.. you know, you could also compare it with plug-ins for textures, perhaps that's a better example. Implementing a new editing mode for meshes or whatever else, should be just as easy as implementing new textures.

Or take externals renderers as an example: is it easy to plug in a new renderer into Blender?

Hope the point gets across now.

[NielsBlender]

@Stukfruit

I take it as 'real deal', don't worry

If you continue to investigate for improvement, 'all the concepts are there but not all implemented as foundation or just partly used as such.'

Niels

ps.
I rather sail the wrong direction with one captain and then the right direction, than I would join a ship of captains that always make a product of no direction.

[matt_e]

Stukfruit: Blender definitely has a lot of old arcane code in it, and parts of it are horribly structured, there's no argument there. However it's a bit of a misnomer to say "I wish there was the UI of Blender with the code of k3d".

Blender's structure evolved the way it did to support its functionality, rather than k3d providing a pretty empty shell to add functionality to. You just can't compare the two unless k3d does have the same kind of interface and functionality as Blender - it may be quite possible that such a cleanly separated segmented code architecture makes the sort of integrated tools and workflow that we have in Blender difficult to achieve in k3d. From my experience of using applications designed around 'everything is a plugin' concepts, the UI suffers, since all functionality gets crammed into the one little area, forced to interface in the same way, with the one UI/workflow regardless of how well it fits (see Max's modifier stack for an example).

I think comparing the two apps is kind of apples and oranges, since it seems k3d's philosophy is to make something that's nice to code in, and Blender's philosophy is to make something that's practical to use.

[macfan777]

I agree, K3D and Equinox 3D are nice, and I'll just have to believe what people say about the cleaner code, but I don't think ANYONE is ready to suggest that they're more powerful than Blender for the end user. The code may be messy, but I know that it works for me. We'll just have to see how Blender holds up in the future and if these other programs can gain any momentum.