The way forward ->

Community
1

I’ve cleaned up the permissions for the forum a bit. I’d like to add people selectively, who are dedicated to helping. Right now, it is:
[ol]
[li]me
[/li][li]Light
[/li][li]PaK
[/li][li]djTomServo
[/li][/ol]

If you want me to add anyone, don’t hesitate to ask.

So, how do we get started? This is going to be a long process, make no doubt about it. Let me lay down a timeline for what I see for this project:
3 Months: Design groundwork has been laid. Good team put together.
9 Months: Basic program working. Design iterated and constantly improving.
20 Months: Program’s fundamentals all in place. Once they are all in place, I intend for it to be developed side-by-side along with a game at a studio, one of our own or one we can pitch it to. It would become a sort of proprietary software owned by a studio.
28 months: Software is complete enough to begin limited distribution (beta phase?).
36 months: Release.

That is a random timeline and I base it on nothing. It is more a series of philosophical goals we’d need to hit. We will need to get the ball rolling by laying down some good design. We’ll need to find programmers to help build, and all of us will need to contribute where we can. I also think the software itself wouldn’t be able to support its development until it is proven- which is why it’d need to be developed as a proprietary tool at a studio, which is the perfect place for it. But I do think, once it has been used in production, we can find users and adopters for it.

So, the first task is to lay down design. I’d like to do this via UML. So, let’s start with something very simple, and come to a decision by the end of this week: What UML editor will we use?
I’ve found three favorable candidates:
[ul]
[li]http://argouml.tigris.org/
[/li][li]http://staruml.sourceforge.net/en/
[/li][li]http://www.sparxsystems.com.au/products/ea/index.html - This is expensive though ($200).
[/li][/ul]

In the meantime, let’s brainstorm some overarching discussion of the design. I’ve done pretty much as much as I can for the time being in the previous ‘Next-Gen 3D software threads.’ So please pingpong something back at me so I can respond- criticism, alternatives, your own ideas, anything. Let’s just get the discussion flowing.

I’d also like to do a weekly voice/web meeting once the ideas start flowing. Since design is all about discussion, forums have their good aspects (allows better articulation and deliberation of words), but they are just so slow to communicate with.

2

As requested; this is my reply that confirms I have access to this thread.

-R

3

If you want to go with UML and free then I’d recommend we go with argouml, because unlike StarUML it is still actively being developed. Last stable release of argouml was last month and last stable release of StarUML was 3 years ago.

The biggest two things I want to see in a new piece of software are that it is intuitive and that it is flexible. Let me define what I mean by those two concepts:

  1. Intuitive. The program must behave exactly as the user expects and stuff needs to be where users expect. Nevercenter have done an exceptional job at this with Silo3D. They call it “zen” modeling. You have what you need when you need it; nothing more, nothing less. If you right click on something it should pull up a context menu of what all you can do to that particular object. Part of being intuitive means being consistent as well… with feature functionality and presentation.

  2. Flexible. It needs to fit into a production pipeline. It needs to come right out of the box with full support for (at least) COLLADA, FBX, OBJ, and 3DS. A clean API needs to be exposed for easy development of further importers and exporters. Also, the control scheme and GUI need to be flexible. I’m an ALT + mouse style user and it pisses me off to end that Max won’t let me work that way right out of the box. By making all hotkeys and mouse gestures remappable, templates for what a user is familiar with can be loaded up and they can jump right to work. Any tool’s properties should be fully exposed as well. If you right click and select an option from your context menu, you should be able to modify its properties to your heart’s content. In fact, what’d be awesome if there was a way to jump straight into the code powering that tool if you’d like to do some power modifications.

Just a few thoughts of mine.

4

What about the developing at a studio? AFAIK if that happens, then it becomes the property of the software that can not be release in any way to the public.

Light

5

Adrian: I’ll check out Argo, thanks.
The intuitiveness is important. I think that customization will be a big part of this as well, but partnered with the consistency you mention. Silo is a really good example of a great niche app- it does what it does and that’s all that it does. Companies get sidetracked doing new, useless features (I mean, those post-processes in Mudbox are cool but, what if you could push another couple million polies instead? Much more useful but less marketable).
Flexibility: That’s what this project is all about. A good description would be a ‘platform’ for custom development. Yeah, it needs to do some things out of the box. But nearly everything should be extensible and customizable.
Maya in this regard gives a good case study. Lots of people- especially Max users- see Maya’s interface as immediately requiring user revision. Well, I think that’s the point of it. The problem is, people are used to Max, and honestly don’t see the huge benefit from customizing Maya’s UI. Power users do and are probably able to work 3 times faster. The biggest hurdle is in presenting this customization, which Maya doesn’t do well. What if, when you first started Maya, it had a UI customization ‘wizard’, that tailored the UI to what you need (modeling vs. animation, hotboxes vs. marking menus vs. shelf, etc)? People would be much less peeved, I think.

Light: You should know better… Kees still owns PuppetShop, no? Ownership agreements are contracts, and contracts are not all the same. The ownership issue will come in time, and for now it may as well be an open-source license. Once some progress has been made we will need to figure out ownership issues and once the product is ready, we can start considering contracts- at that point, we’ll have succeeded, right? Anyway, I’d just not worry about legal ownership stuff yet.

6

Also replying to this thread to confirm read ability, big thanks to Pak for the heads up about this and my apologies for not being around for the last oh month at least:(: Coming up on some major tools milestones (right before thanksgiving no less), but i’ll definitely get my head back in the game.

7

There’s been a death in my family and have to go back to Canada to visit. I’ll use the spare moments I have to read up on UML, cuz I don’t know much about it.

-R

8

Yes, but AFAIK that wasn’t a walk in the park for Kees. Bioware would never do something like this again, let alone EA. I can see small studios might be interested, but not sure if big players would invest their resources for something like this.

Light

9

No it wasn’t a walk in the park for Kees. And I can’t imagine something similar happening again, I agree (developing your personal software on company time). The options are, does it become proprietary software of a big studio- I can see something like this actually, if it was sold properly and it could be shown to save time and money on projects and allow better, non-mandatory tech sharing across projects; or does it wind up that a small studio buys it, and whoever owns the software gets a sort of partnership, and the software remains in their hands but is co-developed at the studio and the studio licenses the software and gets money from licenses, or something like that. Probably none of the above. All we can really hope to do is go forward with what we plan to do and evaluate these opportunities and options as they arise.

My point with Kees wasn’t that it was easy or this is the model I expect, it was that, we have no way of knowing what will happen in this regard in a few years. It is, in many ways, out of our hands. And to set a goal here would disguise much more fundamental goals- namely, to build the best 3D software we can. How it ends up, financially and legally, will be a product of how the software ends up design-wise and technically. The reverse could always drive development instead, but then you’d be a bankrupt mini-Autodesk.

10

Things are a bit crazy for me right now and this very difficult to start project is somewhat on the side. By Christmas I hope to have some design fleshed out for discussion- collaborating over the internet on the first nugget of a program is probably too difficult for busy professionals, we should probably work in parallel on it- I’ll be sure to discuss things as I’m formulating and I expect to throw most of it out when it is presented, but it will give some concrete basis for discussion at least. I encourage everyone to do the same.

11

All right, finally posting. I’m currently physically exhausted from a long day at the Australia Zoo, but my brain is still clear enough to make out sentences. ;). I’m not exactly sure if I should post this here, make a new thread, or post it in the public discussion forum. Either way it’s a start, and I may have to come back and wrap up further.

I understand it’s a long process, and we’re only at the stage of throwing out ideas and such. That said, I’m going to pitch in as well, from my own personal point of view, thrown into the pile of ideas we already have for thought.

Thanks, Rob, for adding me to this usergroup.

I’m typing as I go, but here’s a list of what I’m going to comment on:[ul]
[li]Customisation[/li][li]User Interface[/li][li]Community Sharing System[/li][li]OO Scripting Language[/li][li]API Design[/li][li]Expandability[/li][/ul]

Customisation

Taking most softwares, each comes with its own API for programmers to expand on; some have scripting languages built in for quick, nasty tools; some has built-in features for users to create their own things.

As I’m sure everyone had agreed on earlier, modularity is essential, and probably one of the best solutions for a flexible design. Ideally, we have a shell, and a hundred modules added onto it, which makes taking things in and out easier.

However, most software today (not only 3D) lack one thing - the core is locked from the users. It’s unbelievably hard to, say, override Maya’s Split Polygon Tool. The current solution is to make another one, improving from/using the existing tool. Sure, there is API and we have all the power to do things we can - it’s still horribly difficult to some extent.

I believe a truly customisable software allows the user to:[ol]
[li]Utilise the API provided and develop their own tools[/li][li]Implement into the current pipeline and workflow[/li][li]Replace/update existing tools[/li][li]Maintain the user-friendly design[/li][/ol]

Taking the Split Polygon Tool example above, with this in mind, I should be able to take the API, look at the Split Polygon Tool function, override a few things, plug it in, and replace said tool in the package.

I should be able to use the exact same hotkey I’m used to, click on the exact same menu I know where, and use the exact same way I’m comfortable working but with the new tool. Nothing else changed for the front-end, compared to what is changed in the back-end. If I wanted to expose another option in the Tool Option box, I can too.

This is allowed by having a true Object-Oriented Design 100% throughout the program and development. While we can always add another menu or button, it’s important if we can just get rid of the old one without trouble. If done right, the scripting language (say Python) should be able to accomplish this without having going too deep into the API.

Keep in mind that this is by far, in my opinion, the second most important thing, and is kept throughout this post.

User Interface

This one is hard. People who are comfortable with Starcraft controls may not like how Command & Conquer works. People who plays a real guitar has an amazing trouble picking up Guitar Hero right away with minimal practice. People used to Maya may not like to be forced to use Max the first day.

To pick on somebody, the fact that Microsoft removed all the menus from the top in Internet Explorer and Media Player ticks me. Who the hell came up with that idea, and why did they actually agree and go with it? Wow. I remember the first day I upgraded to WMP 9 and can’t find a way to change my playback until I stumbled on right-clicking on the panel. I also remember when I closed down WMP 9 the music wouldn’t stop, and I had to open it up again, stop the playback, and then close down the program. Very annoying.

On UI I’m both a traditionalist and a believer of innovation. The key is to find a balance between the two. Well, that’s vague.

To break it down, there are two things: the old, and the new.

We’re all used to docked panels, tool boxes, dropdown menus, buttons on the shelves, etc. Things like these are great for people to just jump on, and start right away. I like to take this and add the philosophy of Web Design. In a perfect world, people shouldn’t need to think in order to navigate a website. It needs to flow smoothly, appealing to reading, and allows the user to get where they’re most interested to go in the least amount of effort.

That said, even if we reused the basic windows UI and design it right, we have an user-friendly software.

And here comes the new. I’m sure at one point or another we’ll have a good idea that may boost the program to another level. ICE in XSI for example, was launched only a few months ago and has received a great amount of positive comments. People loved it for how easy it was to use (the old) and the opportunity it opened up. (the new, which was the API exposed through Nodes) They reused what they have, and revamped it into a new box.

UI design isn’t about fancy. It’s not about having cool-looking buttons and windows, and a skin that no other software has. It’s about how fast people can get to know how to use this tool, how fast they can work within the tools provided, and if they needed new tools, we have room for them too. (I’ll talk more about this in the Expandability section.)

The obvious is already known: User-definable hotkeys, shortcuts, good locations for buttons, logical menu structure, etc.

The not-so-obvious is this: What don’t we need?

There are a lot of redundancy in many today’s software, or pointless updates (New look for Dreamweaver CS3! Woohoo! But we didn’t tell you we stopped developing it since version 8 or so!), and worse - old tools never improved (Wow, Mirror geometry in Maya, was it ever fixed?)

So, I’d like to repeat this point again before I move on: What don’t we need in our UI? That’s the question. We already know what we need.

Community Sharing System

This one has been discussed in the public thread, so I’ll not rant for too long. If anything, I like how nVidia’s FX Composer is doing it. They have a tab for browser that links to the online shader database. Click and drag downloads the shader and plugs it right away into the selected model, or available for use. I haven’t seen any other software that has an easier implementation.

I’d like to have an option for the developers to “tag” their tools. Like how Wordpress is doing it, or Digg. Keywords. Related tools.

That’s right. Wouldn’t it be nice if one of the menus in the option box links directly to any published tools with a tag of the name of the tool? It also makes easier for searching, as well as categorisation.

OO Scripting Language
First of all:

  • What languages are we supporting?
  • Are we making up another language of our own?
  • How powerful will this language be compared to C++/C#?
  • How efficient will it work?
  • How fast can the developer make that tool?

All right. So, I like the idea of UnrealScript. It’s not the most beautiful language in the world, but its expandability is amazing. It codes like C++ without all the excessive worries, and it works like a charm.

Wouldn’t it be nice if we have a scripting language (quick type-up dirty tool) that uses the fundamental design of OO? It will speed up tools development by a mile. And I’m a fan of reusability as well.

The ideal situation is that 100% of the API is open for the scripting languages to access.

API Design

To recursive is divine. The simpler the better. The lighter the better. Really. That’s all I’m saying.

Expandability
The cool thing is we’re already going for modules, parts, plugins, addons, macros, whatever you like to call it. These things are awesome tools we can add to what we already have.

But one thing we need to keep in mind is that our shell is very important. The basic mould, the fundamental container that should abstract everything and absorb new things easily. I’m not saying we should design the core to fit what we will have in 10 years - that won’t happen. We can’t know what is going to happen in 10 years. So, what we can do, is to keep our things clean (if it costs the program a 10% efficiency to have a clean code and full comment and great logic, the hell I care; we’re not running 60fps games) and make everything interchangeable.

We need to constantly look out for what other software is doing. True, we can steal nice tools and nifty options, but that’s not the main thing we need to look for. What’s important is if we can make our program very flexible for adding new features.

Why? By the time we noticed that we’re behind on some tools, maybe our community already got one set up roughly and already featured on our database for others to use!

That’s important. The most.

All right. That is a lot of ranting, but I hope I got my ideas through. More to come if I can get feedbacks on these.

I look forward to that design you talked about, Rob, and good night everyone. Thanks for reading. :]

12

Sorry, haven’t had a chance to read this until now. Responses:

Customization: You’re right on. A truly OO approach vastly simplifies this. Let’s say Maya’s Split Polygon tool was a class- you should be able to overwrite methods or extend the class, whether you have the source or not. And since you aren’t really changing anything outside of the functions (they still take and return the same), nothing will break if your code is correct.

UI: Again, having an OO approach will enable us, and users, to develop their own interfaces much easier. UI is just a layer- as long as our underlying layers are modular and flexible and easy to use, what the UI is like doesn’t matter at all.

Scripting Language: I’m against reinventing the wheel. Python is very popular, especially in the 3D community, and we all love it. It fits perfectly with our OO approach as well.

Expandability: We are of the same mind on this. Core is extremely important and focusing on modularity will enable us to keep things clean and up to date. If the core needs to be replaced or rewritten for speed or re-design, doesn’t really matter as long as everything works with it, which will only happen if our overarching design is strong.

13

Another interesting schematic editor to check out:
http://www.mindjet.com/en-GB/default.aspx

A bit pricey, but much easier to use than UML I think, and may give us a leg up (UML is much more complex and has a higher learning curve than I’d hope, and I think is somewhat of a barrier right now).

I’ll have a full statement tomorrow night but I just thought I’d post that for now.

14

Can we start this up again? I want a reason to be excited anbout tech art again sighs

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.