Please don't get rid of edge and face loop select preview

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

osxrules
Posts: 0
Joined: Wed Jun 02, 2004 6:34 pm

Please don't get rid of edge and face loop select preview

Post by osxrules » Mon Sep 05, 2005 9:34 pm

I don't know if people have tried out the 2.38 builds and found this but the edge and face loop select modes are missing. They have been replaced by alt-right click and depend on your selection mode.

I'm finding this very frustrating for a number of reasons.

1. There is no preview anymore so when I select muliple face loops, I can't see if there are some that will select too many faces. Before, if I noticed a face loop would select too many faces, I would resort to individual selection.

1b. Having no preview also means that I can't drag my mouse over the model and quickly check that my topology is correct.

2. Now because there is just one command, it means that I have to switch selection modes in order to change selection type. This really slows things down if I'm using a combination of edge and face selections in vertex mode.

Here is the new workflow to select a faceloop then a vertex loop:
1. in vertex mode
2. hit alt-right click for edge loop select
3. switch to face mode
4. select faceloop
5. switch to vertex mode

The old workflow was:
1. in vertex mode
2. alt-b to select edge loop
3. shift-r to select face loop

Now, I was told the old way was a hack and this new way is correct but what's the point if it's less functional and slower?

If the preview showed automatically when the alt-key was pressed and you dragged over the object, that would help considerably but having to switch select modes is a slow down. I know that it doesn't make much sense to allow edge loop selection while in face loop mode but the way it is now, you can't do face-loop select in vertex select mode.

(sob story coming)
If that wasn't bad enough, I don't have a lot of movement in my left hand so trying to do alt-shift every time I need a multiple loop selection isn't just awkward, it's painful. At least the other loop select modes had a menu option.

They also made the cursor change, which doesn't happen now.

Even if you took out the layers buttons that are cluttering up the menu bar and move them to the bottom half of the outliner so they can be nameable, hierarchical and infinite and put in two little buttons called E and F for edge and face loop select and bring back the preview, that would be so much better.

TheFallenWeeble
Posts: 0
Joined: Tue Jan 21, 2003 6:11 pm

Post by TheFallenWeeble » Fri Sep 09, 2005 4:08 pm

I agree. I prefer the keyboard shortcut method (or at least *some* keyboard shortcut) and I'd really like to see the loop selects available in the Select menu.

ALT+CLICK is especially frustrating to me (and maybe a couple other linux users) because alt+click variations are bound by my window manager (alt+left_click = move window, alt+middle_click = resize window, alt+right_click = window options... really helpful for borderless windows, like how I run blender), so I can't even use this functionality right now. I'd prefer a keyboard shortcut, but failing that, making it available in the Select menu would at least give me a workaround to get loop selection.

EDIT: just double-checked, CTRL+ALT+CLICK works for me, so I guess I do have *some* viable workaround, but it'd still be nice to have it as a menu option (and I agree that the preview was a helpful feature, too). Besides, it was nice not having to change edit modes (verts, edges, faces) just to a loop selection.

Yfkar
Posts: 0
Joined: Thu Feb 19, 2004 8:32 pm

Post by Yfkar » Sun Oct 23, 2005 11:51 pm

I agree with osxrules.

Duoas
Posts: 0
Joined: Mon Apr 18, 2005 10:32 am

Post by Duoas » Sun Oct 30, 2005 12:37 am

I'm in near total agreement.

:arrow: The difference between vertex, edge, and face select modes are cosmetic: they exist for convenience. To forcibly bind other functionalities to a visual representation (as opposed to a visual model) is a form of programmer-as-user-syndrome (think just a little bit and you'll understand what I mean).

I'm not sure what Alt-B is doing now, but it appears to be pretending it's XSI. Stop it, OK? The little 'render this window' is all the Quick-Render needed. (I tend to render to a separte window, but Blender allows you to render to an area, which can be automatically updated if the user makes changes.) If we really want a small part, do it like XSI and render in quadrants, starting in the center and working outward until the render frame is filled, the user makes a change, or the user presses Esc, thus conforming to expected interface behavior while simultaneously providing a new and useful functionality.

:arrow: I can't object too much to having the hotkeys changed, since Alt-B is a pretty awkward choice to begin with. I notice that neither Ctrl-F nor Ctrl-E are used: these are more convenient to the left-hand and have amazing mneumonic powers (just like 'B' for 'box select' and 'A' for 'animate'). As usual, Shift can be added to select additional Faces or Edges.

The 2.3 Blender Manual lists Ctrl-F as 'flip selected triangle edges' which, as far as I can tell, doesn't do anything...

Also, the visual cue (preview) is a wonderful feedback function. I'm sure that powerusers like oxrules and myself aren't the only ones who use it regularly. Remember: loop selects are one of the most useful and powerful features available to a polygon modeller. Don't cripple it!


:arrow: Another thing that we must be wary of doing is overloading shortcut keys. I'm well aware that there are a limited number of keys available, and not everything will get what it wants. It's just a part of UI design to sort those out. The most useful and most used features should have first pass: give them the strong mneumonics and the conveniently thumbed positions. Lesser features are trivia to begin with, and so their shortcut keys need not have as strong a mneumonic or positional association.

If the same key must be used for two different features, there should be some salient rationale or relationship to it. In other words, the end-user should be able to quickly grasp it as part of the natural function of the program.

Early Blender design documents understand this concept. All windows are expected to employ similar key commands (as much as possible); the user need not memorize a whole different set of shortcut keys for each window, nor even have to notice which window he's using. We see this in the 'S' --> scale. It works in every type of window: 3D View, UV/Image Editor, IPO Curve Editor, etc. The same with Ctrl-MMB to scale the view. It works everywhere.

Even in this broken version, the Shift key is used as its application level idiom dictates: select additional objects.

Here's an example where the foregoing was not followed: Ctrl-T and Shift-J (Alt-J works too). They do the same thing: one converts to triangles and the other to quads. The basic operation is the same: change the type of faces. But the commands use differing bucky-bits to accomplish the task. That is a design incongruity, and appears to the end-user as a bad hack, as if the UI design team didn't really know what to do with them.

:arrow: Finally, always, always, always make every feature of a program available from a menu. Yes, there are occasional exceptions, but for an international, multi-platform program like Blender they are few. Keyboard layouts differ, window managers interfere, and mice come with less than three buttons. The user should always have a way to access a feature should it be otherwise obfusated for him.

This also encourages learning about the program. By posting features in menus, users see what things are available, try them, and afterward use them regularly. Why spend time coding something that will be ignored? I won't lecture on listing shortcuts with the menu item.

:arrow: Conclusion and suggestions:
- Fix the shortcuts as described above.
- Keep the visual preview cue.
- All program functionality should be accessible from an appropriate menu.
- For different edge loop choices give a quick pop-up menu asking what type of loop is desired (such as the 'around corners' option in XSI).

End transmission.

Zarf
Posts: 46
Joined: Mon Oct 14, 2002 3:54 am

Post by Zarf » Sun Oct 30, 2005 7:49 pm

Duoas wrote:I'm in near total agreement.

:arrow: The difference between vertex, edge, and face select modes are cosmetic: they exist for convenience. To forcibly bind other functionalities to a visual representation (as opposed to a visual model) is a form of programmer-as-user-syndrome (think just a little bit and you'll understand what I mean).
My 2 cents.

This has been true in the past, it is less so now, and hopefully even less in the future. For instance, the new subdivide code is sensitive to whether or not you are in face/vertex/edge mode, as it should be. This actually ADDS a lot of functionality. I am working on improved merge code that is sensitive to whether or not you are in vertex/face/edge mode (see silo for reference.) For mixed modes it merges based upon what is 'proper'.

There is also 'select edge ring' functionality in CVS, that if if you use this in Vertex mode you get face loop selection for free (although I am not a fan of being able to select edge rings/edge loops while in vertex mode at all, but thats not my decision is it?)

I really dont understand what advantage there is to having selection What is and isnt ann edge loop/edge ring is very clearly defined, so there shouldnt be any suprises from your selections. Further its modal which is just plain nasty. Perhaps I dont understand, what is so great about it?

As an aside I would like to point out that blenders current method of 'shift-click' to add to selections works 'ok' for simple selection tools, not so great for more complicated ones like edge loop and edge ring select. I submitted a patch to the patch tracker to add keyboard access to edge loop and edge ring select. Say you select an edge loop, then tell it to select an edge ring, it will step through all the edges selected and run the edge ring select function on them. You can do it the opposite way as well or whatever, no more of that 'shift click' a couple dozen (or hundred!) times nonsense to build complex selections. Still, if you just want to add/subtract ONE specific edge loop/ring to your select set, shift-click works great in conjuction with keyboard access to these functions (take that SILO&Wings!)
Duoas wrote: The 2.3 Blender Manual lists Ctrl-F as 'flip selected triangle edges' which, as far as I can tell, doesn't do anything...
Take two triangles that share an edge (basically togather they form a quad). 'Ctrl-F' will flip the edge they share (usefull for game modelling mostly)
Duoas wrote: Also, the visual cue (preview) is a wonderful feedback function. I'm sure that powerusers like oxrules and myself aren't the only ones who use it regularly. Remember: loop selects are one of the most useful and powerful features available to a polygon modeller. Don't cripple it!
Really I dont understand, if youve been modelling long enough you should know what constitutes a faceloop/edgeloop/edge ring and what dosnt. Its well defined. Perhaps this option should return and make it configurable by the user, because I sure as heck hated it.
Duoas wrote: :arrow: Another thing that we must be wary of doing is overloading shortcut keys. I'm well aware that there are a limited number of keys available, and not everything will get what it wants. It's just a part of UI design to sort those out. The most useful and most used features should have first pass: give them the strong mneumonics and the conveniently thumbed positions. Lesser features are trivia to begin with, and so their shortcut keys need not have as strong a mneumonic or positional association.
Agreed, shortcut keys are a mess right now and need to be sorted out. This is one of my biggest problems with blender ATM, everything seems to be a 'hodge podge' as far as how you aceess commands when modelling. Some things are in the w-key menu, others are in the toolbox (which is inexplicably context-insensitive) still others are in strange hotkey configurations. People should sit down and take a long hard look at this and sort it out. Personally I am in favor of user assignable hotkeys and a toolbox that wraps 99 percent of all functionality and is highly context sensitive yet allows the user to navigate easily backwards in its hierchy. Broken also has a interesting new toolbox for editing mode in tuhoppu I believe that looks like it has a lot of merit.

Duoas wrote: Here's an example where the foregoing was not followed: Ctrl-T and Shift-J (Alt-J works too). They do the same thing: one converts to triangles and the other to quads. The basic operation is the same: change the type of faces. But the commands use differing bucky-bits to accomplish the task. That is a design incongruity, and appears to the end-user as a bad hack, as if the UI design team didn't really know what to do with them.
The command is just plain 'j' for join to quads. Ctrl-T converts the quads to tris with the veertices winding one way, ctrl-shift-T with them winding the other. Your point is well taken though, since just plain old 't' dosnt do anything(!) The biggest argument I hear for not fixing these issues is that it will 'break' old docs and tutorials and quite honestly, I think thats lame. A system where every command/function could be found in a sane way and was grouped with similar commands would allow the user to 'fix' the tutorial as they went along.

You know now that I think about it, the whole idea of binding key functions to keys that represent the first letter of their 'name' is probably bad idea. Blender works with a lot of different types of data, and there are many operations on each type that are conceptually similar and should therefore share the same key-shortcut, but do not share similar names (rotate and 'tilt' come to mind). I think this is why I have never minded the default keysetups in SILO, muscle memory trumps phoenetic associations.
Duoas wrote: :arrow: Finally, always, always, always make every feature of a program available from a menu. Yes, there are occasional exceptions, but for an international, multi-platform program like Blender they are few. Keyboard layouts differ, window managers interfere, and mice come with less than three buttons. The user should always have a way to access a feature should it be otherwise obfusated for him.
This is where I think a better version of the toolbox comes in, kind of like wings INSANELY context sensitive right-click menu but a wee bit more intelligent in how it allows the user to navigate it. In addition to all the things you mentioned, lets get real: were running out of damn hotkeys, and even the current keyboard layout is making less sense by the day.
Duoas wrote: This also encourages learning about the program. By posting features in menus, users see what things are available, try them, and afterward use them regularly. Why spend time coding something that will be ignored? I won't lecture on listing shortcuts with the menu item.
Also you can put links to option boxes next to menus, 'radio buttons' to permantly alter the state of how the functions work and more.
Duoas wrote: - Fix the shortcuts as described above.
- Keep the visual preview cue.
- All program functionality should be accessible from an appropriate menu.
- For different edge loop choices give a quick pop-up menu asking what type of loop is desired (such as the 'around corners' option in XSI).
I agree about the shortcuts----going to have to wait until the event system refactor probably though

Make the visual preview cue an option I would say.... I think its nasty and I know I'm not a lon.

3rd item in complete agreement.

4th item intrigues me, what the 'around corner' option? does that have to do with selecting loops that are interuppted by poles with a valence of 3? I could see how that would be a really nice option to extend vertex loop selection.... shouldnt be to hard to code either.

Cheers
Xarf

Duoas
Posts: 0
Joined: Mon Apr 18, 2005 10:32 am

Post by Duoas » Sun Oct 30, 2005 10:42 pm

:arrow: The selection modality of course will affect certain features. For example, it would make no sense to try to select an edge loop (or what's now called a vertex loop) when in face select mode. Face select mode is purposefully exclusive of the concept of individual edges and vertices. That's reasonable.

However, to impose an artificial restriction based upon visual mode goes too far. It is very common to model in vertex select mode. And, as I noted before, vertex loop selection is a very powerful and useful feature, one which is also commonly used. Forcing the user to change to edge select mode just to get a vertex loop is, to my mind, akin to restricting a car to making left turns only. You can still get where you want, but it's a pain to do something simple.

In other words, face select mode exists to logically group vertices and faces. This permits you to manipulate them as a whole object. You are still manipulating vertices, but you are treating them specially. The faces still exist in vertex select mode: I can still select four vertices and 'F' make a face.

The point: Forced modality makes simple things hard.

:arrow: Your comment about doing what is 'proper' is close to what I want. The word I would employ is to do what is 'appropriate'. This allows more flexibility than does someone's idea of what is 'proper'.

Forgive me, but that seems to me the way you are coming across: this is the visual/conceptual model, this is what it represents, and this is the only way you can view/manipulate it. That is, frankly, an antagonistic form of bad programming practice: people (end-users) absolutely hate it. One of the main reasons is because it is the point at which the computer begins to tell a human how to think. It's insulting and degrading to the owner of the tool. (I am not making this up!)

Computers are used for the purpose of applying abstractions to data. If all you wanted to do was crunch numbers, some guy on an abacus could do nearly as well.

The abstraction itself may vary by context. In other words, abstractions are abstractly qualified. This is what you are aiming for when you say: the function should act proper (appropriate) to the mode. This is nothing new, human thought and speach operates in this manner. You may think I'm preaching to the choir, but I have a point.

The English language is a prime example: one of the reasons for its popularity and expressiveness is that there are usually more than one way to say something. When it was codified in the late 16th/early 17th century, scholars understood this power in the human mind:

What have you?
What do you have?
You have what?

These mean the exact same thing in an identical context. One or the other may sound stilted in the working context, but the meaning is clear only because it is related to the context (and tonal inflection).

However, that context doesn't prevent me from asking a different question. As long as it can be applied it is appropriate.
So I couldn't ask: Where is she now? (Who is this she of whom you ask? What does she have to do with what I have? Were you talking to me???)
I could ask: Where did you get it?. That's an entirely different question, but fully applicable in the operating context.

Do you see what I'm trying to say? Adding functionality should never restrict operability. Operability should only be restricted by the following question: Is it sensible (possible within reason) to do x here? (Be careful not to extend this to mean more than it does. For example, just because 'S' scales things in all windows doesn't mean you should run off and code the ability to scale individual panels in the Buttons window.)

The point: As long as it can be reasonably applied, it is appropriate.

:arrow: Final point about the modal preview.
Firstly, you need to be more careful about how you express you view. Please don't say "if you've been modelling long enough you should know". That's a put-down, not a valid argument. I've been modelling long enough to know there are often thousands of vertices crammed all together in the same vicinity on my 2D monitor. The definition of what constitutes a loop has nothing to do with it. Identifying a loop's citizens does (or just as often, predetermining that you have selected the desired loop apart from nearby neighbors).

Secondly, modality is not forced here. Box select is a doubly-modal tool (a very unusual feature, but no one complains about it. Scaling, rotation, extrusions, cuts [subdivisions], etc. are all modal). The problem is not in the modality but only in what you perceive to be a useless feature. I, and others, disagree. It is when you endeavor to enforce you're preference upon us that conflict ensues. You have made it clear that you hate it.

Fortunately, you have suggested the perfect resolution: make it an option. Options are always a good thing :) And, in this particular case, appears to be something that would be trivial to implement.

Thirdly, don't depreciate the standing idiom and power of shift-selecting additional edge loops. It is a form of mass-select which I have often wished I had (this before I figured out that I did in fact have it).
In the end that is the purpose of a loop select: a directed mass-selection.

The point: Respect others' preferences by providing options.


:!: I hope that I have adequately expressed my reasons and feelings on the subject. Loop select is something I use often, and I enjoy it's current (2.37) power. I'm using Softimage XSI at school, and one of the few things which disappoint me about it is its lack of friendliness when using its edge-selection tools. (That and I keep scaling things I mean to delete... :oops: )

Duoas
Posts: 0
Joined: Mon Apr 18, 2005 10:32 am

Post by Duoas » Sun Oct 30, 2005 10:56 pm

Sorry to double-post, but the last one was so long... I forgot to answer your intriguing question.

Yes.


Also, you're correct about using the first letter for names. It is not always appropriate. Only for high-ranking features. Also, it need not be the first letter; only something that associates well with the function.

Zarf
Posts: 46
Joined: Mon Oct 14, 2002 3:54 am

Post by Zarf » Mon Oct 31, 2005 1:11 am

Duoas wrote::arrow: The selection modality of course will affect certain features. For example, it would make no sense to try to select an edge loop (or what's now called a vertex loop) when in face select mode. Face select mode is purposefully exclusive of the concept of individual edges and vertices. That's reasonable.

However, to impose an artificial restriction based upon visual mode goes too far. It is very common to model in vertex select mode. And, as I noted before, vertex loop selection is a very powerful and useful feature, one which is also commonly used. Forcing the user to change to edge select mode just to get a vertex loop is, to my mind, akin to restricting a car to making left turns only. You can still get where you want, but it's a pain to do something simple.
Well let me clarify where I am coming from with this...

For a long time I was a user of apps like Wings and similar apps where sensitivity to selection modality was not only enforced strictly but ALSO gave the app a lot of its power. There is forinstnace, no 'face loop selection' in wings because it is a function that is easily built by combining other commands and exploiting selection mode changes: select edge, hit 'g' key to grab edge ring, thne hit 'f-key' to convert selection to faces, there you go, you selected a face loop using a few small 'general purpose' tools that can be 'combined' to take care of 'special cases'. (you can actually do this now in blender it just takes more steps...) This is just a small example of exploiting the 'strict modality' of the selection state in wings/mirai for the users advantage, there are dozens if not hundreds of others.

Anyway I do realize that with blenders multi-selection mode things are not that simple, but instead of taking the multi-selection nature of blenders modeller and working with it to create a slightly better way of looking at things we instead are creating a system where 'for some purposes the selection state means something, for others it dosnt mean crap and we are in fact just working with vertices.' This is NOT the way to go in my opinion and as a user I can say that it just ends up confusing the heck out of me. However you made some good points yourself that need to be considered and I think we can both agree that the system as it is needs a lot of work. So how do we satisfy the needs of all parties? I
Duoas wrote: In other words, face select mode exists to logically group vertices and faces. This permits you to manipulate them as a whole object. You are still manipulating vertices, but you are treating them specially. The faces still exist in vertex select mode: I can still select four vertices and 'F' make a face.
I cannot really agree with this. A face is not simply a collection of vertices, even though vertices are part of the data that it is comprised of.
Duoas wrote: Forgive me, but that seems to me the way you are coming across: this is the visual/conceptual model, this is what it represents, and this is the only way you can view/manipulate it. That is, frankly, an antagonistic form of bad programming practice: people (end-users) absolutely hate it. One of the main reasons is because it is the point at which the computer begins to tell a human how to think. It's insulting and degrading to the owner of the tool. (I am not making this up!)

Computers are used for the purpose of applying abstractions to data. If all you wanted to do was crunch numbers, some guy on an abacus could do nearly as well.
You seem to be contradicting yourself here... acording to the first block of text I quoted you seem to imply that its not up to the computer to tell you how to look at things and then in the next you show an example of someone who is doing it all in thier head and creating their own abstractions and saying computers should allow for more than this? Which is it?

Anyway 'forced' modality may or may not be a good thing in my mind. Certainly users of wings/Mirai/Silo ect have no problem with being 'strongarmmed' into looking at and working with the data they are using in a particular way. I dont know if you disagree, but I am of the mind that one of the roles of the programmers is to decide how best to represent the data to the user so that they can have an effecient tool. Otherwise we might all just do it 'by hand' with abacus'....

Regardless 'Strict' modality when it comes to selections and tools may or may not work in blender, but I think we at least need to clarify things and set some guidelines for the interface and what is permissable and what isnt.
Duoas wrote: :arrow: Final point about the modal preview.
Firstly, you need to be more careful about how you express you view. Please don't say "if you've been modelling long enough you should know". That's a put-down, not a valid argument. I've been modelling long enough to know there are often thousands of vertices crammed all together in the same vicinity on my 2D monitor. The definition of what constitutes a loop has nothing to do with it. Identifying a loop's citizens does (or just as often, predetermining that you have selected the desired loop apart from nearby neighbors).


If I offended I am sorry, but I still stand behind my point. If you know what constitutes a loop you dont need a computer to help you identify its 'citizens'. Thats why I dont like it. If you do thats your own personal prefercence so put it in an option or something I say. If forced I would have to admit that it makes no less sense than selection highlighting (which I like).
Duoas wrote: Thirdly, don't depreciate the standing idiom and power of shift-selecting additional edge loops. It is a form of mass-select which I have often wished I had (this before I figured out that I did in fact have it).
In the end that is the purpose of a loop select: a directed mass-selection.
Actually If you reread what I said I think the shift-clicking to build previews is a GOOD thing and combined with full keyboard access to complexselection tools would put blender slightly AHEAD of silo and wings in at least ONE respect.
Duoas wrote::!: I hope that I have adequately expressed my reasons and feelings on the subject. Loop select is something I use often, and I
It would have helped me to understand what you were responding to if you had used quotes. I am sorry I am not trying to be insulting but I did have a small bit of trouble udnerstanding which part of my post you were responding to at any given time. Overall though I think I got it all :)
[/code]

Jorge
Posts: 0
Joined: Fri Jul 29, 2005 6:40 am

Post by Jorge » Sun Nov 06, 2005 7:28 am

The 2.3 Blender Manual lists Ctrl-F as 'flip selected triangle edges' which, as far as I can tell, doesn't do anything...
Nothing to do with this discussion, but just so that you know, I use this function a lot. Along with edgeloop removing, it's my basic rearrangement tool to remove triangles from a mesh. Look at this "before and after" image. The model on the right had all triangles removed.

Howitzer
Posts: 0
Joined: Fri Jan 14, 2005 4:47 am

Post by Howitzer » Wed Nov 09, 2005 8:19 pm

I also agree. I don't like how I must alt-click to select edge loops, although it does not bother me too much... which is why I'm not writing so much about it like you folks are.

I mean, seriously... what else needs to be said? We don't like alt-clicking, we like the old alt-b/shift-r.

With the understanding that Blender is for the community, it might be a good idea to listen to them.

My two cents.

Bellorum
Posts: 0
Joined: Wed Jan 21, 2004 3:27 pm

Post by Bellorum » Wed Nov 09, 2005 9:32 pm

Howitzer wrote:We don't like alt-clicking
I do, actually.
There's no such thing as democracy. There's only the tyranny of one, and the tyranny of many.

Howitzer
Posts: 0
Joined: Fri Jan 14, 2005 4:47 am

Post by Howitzer » Wed Nov 09, 2005 9:57 pm

To be honest, I couldn't care either way. But- I do have a preference to alt-b... and when I saw these people voicing their very long winded opinion on it I thought it would be helpful to put in my two pennies.... a sort of read this if you don't want to read all of that

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Nov 10, 2005 9:13 am

"With the understanding that Blender is for the community, it might be a good idea to listen to them. "

This is a big missunderstanding.
Blender is not for the community. It is for programmers. Think about it, why else is there no user section on blender3d.org?

Bellorum
Posts: 0
Joined: Wed Jan 21, 2004 3:27 pm

Post by Bellorum » Thu Nov 10, 2005 1:59 pm

joeri wrote:Think about it, why else is there no user section on blender3d.org?
Because there was already a very active user community at elysiun.com, when blender.org was introduced? :roll:
There's no such thing as democracy. There's only the tyranny of one, and the tyranny of many.

Howitzer
Posts: 0
Joined: Fri Jan 14, 2005 4:47 am

Post by Howitzer » Sat Nov 12, 2005 1:11 am

Ok. That was enlightening. So, thats a 'no'?

Post Reply