Where to start with BIG projects?

#1

Hey guys,

I’ve been a hobbyist programmer for a long time now but I’ve never really jumped in and done anything real with it other then some Lightwave LScrips and Maya MEL scripts… A few simple Python things here and there and the usual beginners C/C++ stuff. Lately, I’ve been digging into OpenGL. Anyway, I’ve been noodling around an idea for a bigger 3D project. Much bigger. But I’m having trouble figuring out where to start.

First a little background: I’ve been a CG animator/ Technical director for about nine years now. I’ve had a long time to think about the way I personally want things to work in an animation Program. I’ve collected these features and wrote up a list and even started writing a manual of sorts.

What I want to make is a nice node based 3D animation program. It would be free and run on Linux and Windows. It wouldn’t have a modeler or renderer but instead use LightWave and OBJ format geometry (for Sub-D) and output to RIB and possibly VRay (once the standalone version is released). The Main focus will be on the interface and user interaction. I’m also planning on making it very extensible and open to other programmers so that other people could add things as simple as little plugins to full blown modules and geometry types. So, in that sense it might wined up being Open Source as well.

My first issue is that I know exactly how the program should work; I know what the interface looks like (made a mock up in Flash), how thing act and react and all the features I want in it… But I have no clear picture of how the backside should be organized.

The other issue is that I’ve only toyed with C and C++ and I’m not very happy with how these languages work. I really love Python but it’s just not going to be fast enough to handle the real number crunching for things like IK and Dynamics. That also rules out any of the other languages that are interpreted. One language that intrigues me is Objective-C but it’s not very well supported on any other platform other then OSX and Linux. Will GCC compile Windows binaries under Linux? Other then that, I don’t really know of any really good, fast, object oriented, language that is as well supported as C/C++.

I know, right off the bat that I’m totally biting off more then I can chew but I’m hoping that I’ll be able to find other developers to join in or at the vary least, provide advice. Also, I really feel like it would be a great program since I’m primarily an animator myself and I think I have a lot of really cool novel ideas. And, even if there not as innovative as I think they are, what the heck do you want for free. Actually, I have this sort of fantasy that a free, high end 3D animation program is just what is needed right now to give a boost to the community. I mean, there’s really nothing out there like this right now (Ok
other then Blender). And, if it turns out to be as cool as I’m imagining, it might even give a little push to the big guys (Maya, Lightewave, XSI).

I can post a more in-depth feature outline of the program if anyone is interested.

Thanks for any help,

-=GB=-

Galen Beals,
Animator/Techincal Director,
Bent Image Lab

#2

I don’t want to rain on your parade or anything, but I think a full-blown 3d animation program might be a bit too much work.

For one, for things like IK and dynamics, as you have correctly identified, you really need to write it in C++, and if you’re not that confident with it you may well find you come across problems more related to limited knowledge of the language rather than the rather nightmarish maths involved.

One of the best reasons for using C++, aside from its speed, is the large amount of information for solving complex problems alrady available in this language, and the amount of existing, stable, optimized code. For your particular application I would recommend looking very closely at the standard template library and the Imath libraries, plus a good GUI library like gtk+ or QT

And that’s before you even get into the nightmare of UI design. Understand that you will spend most of your time building and debugging the user interface (by this I mean fixing widgets that won’t resize or respond, tracking down random crashes when you click on a particular button) rather than doing th exciting bits.

Having said all that, hell I applaud your idea! I say run with it. As for how to proceed: one word.

PLANNING

first thing to do with any large project (especially one as complicated as this) is sit down with a pencil and paper and design everything. Give yourself a limited feature set to implement that you are confident you can make workj and do not get distracted by the fuggy haze that is all those “cool” features that you want to add.

Outline how every one of these features works, how it fits in to the overall structure of your application.

Then sit down again and for each one of those features work out all the maths and algorithms involved (linear algebra and numerical methods, quaternions etc). Make sure you are 100% up to speed on all the matrix maths (of which there will be a lot), make sure you know what algorithms you will use, and what types of data structures you will need. Then make sure you know the libraries you will use to implement these back to front and inside out.

It’s aways more fun to jump straight in and start coding, but if you don’t want to have to start from scratch 20 times over, careful planning will make your life easier.

Good luck!

#3

Yes, a good plan is worth a lot. About the languages, what about combining Python an C/C++? You could write the numbercrunching in C/C++ and write the higher level code in Python.

#4

Good advice, but before you start planning how your tools will work and how the interface will look, I really suggest thinking about how your data will be organised and represented.

How will your objects be stored internally, and how will they interface with the tools and other fucntions.
How are objects represented and managed on an individual basis and on a scene level? What kind, and how much data will each object hold? How are they linked together? Will there be a master (root) object that will contain and manage the individual objects, or do objects manage themselves?
What about viewport culling? Will you use BSP? or FOV?

Essentially, once you have a solid design for how you data will be stored, represented and manipulated, you can then begin working on how the various methods will work on them, and then how they will work with the UI.

heck, there’s a lot going on… and most of it has no visual representation. That to me would be the most important thing! If the motor don’t work, a slick chassis and a nice dashboard aren’t going to save the car!

well, just an opinion! but definately… PLANNING!!! (for everything)

#5

I’ve been involved in planning many HUGE new projects and playmesumch00ns and Jhavna hit it straight out. If you don’t plan on what your main feature list is, how it will interact and how the data structures are designed and used then I guarantee you that you will be doomed to either failure or many rewrites. On a couple of the projects I worked on we had several teams spending a couple months planning different portions of the overall design and then more time trying to integrate all the pieces together. This included flowcharting at many levels, storyboarding user interaction and gui interfacing, data models and even pseudo coding mock ups as experiments for new technologies. While spending so much time seems alot we were able to take a 2-3 year development schedule and compress it into 8 months. I’ll admit it was compressed into 8 months because we were slave driven into it and often worked 100 hour weeks. But we knew what we were doing and how to get it all done with few problems along the way.
As for using python I would highly suggest using python with c/c++ coding. You’ll find that scripting can be a MAJOR advantage to getting some of the smaller coding (larger to the user) features done.
The one thing I would highly recommend is to always think of your program from a users point of view and not as a programmers. Once you get coding you will find that what you as a programmer finds as the best way is a nightmare for a user and vicea versea.
GOOD LUCK

#6

Playmesumch00ns,

One of the best reasons for using C++, aside from its speed, is the large amount of information for solving complex problems alrady available in this language, and the amount of existing, stable, optimized code. For your particular application I would recommend looking very closely at the standard template library and the Imath libraries, plus a good GUI library like gtk+ or QT

This is a good point. I guess I’m really not that opposed to C++. I’ve been giving it a lot of thought and I figure that since I already know all the basics I‘m probably not that far off. I’m not saying I could start today in it but I think I can get around in it OK for most of the abstract stuff. I already have a book on STL and was already planning on using things like vectors, linked lists, all the different sorts and stuff like that. I’m pretty lazy so when it comes to ready made classes, I’m there.:wink: As far as TK and QT go, I’m not sure yet. I’ve noticed that the connections for Python to TK are a lot simpler and easy to use then they are in C++. QT seems like a behemoth to me. What is Imath by the way?

And that’s before you even get into the nightmare of UI design. Understand that you will spend most of your time building and debugging the user interface (by this I mean fixing widgets that won’t resize or respond, tracking down random crashes when you click on a particular button) rather than doing th exciting bits.

Yeah, this is kind of funny to me. Since I’m mainly a visual person, I usually think of everything in visual terms. UI design is actually the part I’m most interested in. It’s also going to be one of the main focuses of the software. Not so much in pretty buttons and drop shadows and silly things like that but in the arrangement and accessibility of everything. Building an environment where you have access to all the information that you need but still have lots of room to see what you’re doing is of great importance to me. It’s one of the main reasons I wanted to do this in the first place. Anyway, I was actually thinking of designing my own UI library in OpenGL! I’ve already seen one out there but it looks kind of ugly to me. Plus, I’m going to be messing around with all sorts of moving panels, floating buttons, and transparency. I’m hoping it will make the UI nice and fast and take a lot of strain off the CPU. Plus it’ll help making it cross platform
Right? I know it probably sounds silly to most of you guys and please, correct me if I’m wrong but there already seems to a lot out there in the way of hardcore math libraries. So to me, it’s sort of looking like a ‘pick and plug in’ job. I even found an IK library that looks pretty cool. I’m also toying with the idea of throwing in a little of one of the game libraries out there for some real-time physics and collision detection (While you animate!) Does any of this sound feasible?

Give yourself a limited feature set to implement that you are confident you can make workj and do not get distracted by the fuggy haze that is all those “cool” features that you want to add.

Yep! Good advice! That’s exactly what I’ve been doing too. I’ve been writing up a plan of attack that starts with the main interface and the node API. Nodes will be self contained objects stored in .dll/so files. So basically, all the features will be like plugins to the main App. They’ll inherit there basic transforms and state data from a main node of there type which is based on the module they come from (ie., Global, Setup, Animation, Physics, and Render). I won’t be writing any of those until everything works in the main App. Still there’s a lot to do in that sense; all the panels need to be able to quickly retrieve and display all the data, everything to do with motion will be handled here as well so all the key frame interpolation nodes and motion controller nodes will need to be written. Basically
A lot of nodes! :slight_smile:

Stew,

Yes, a good plan is worth a lot. About the languages, what about combining Python an C/C++? You could write the numbercrunching in C/C++ and write the higher level code in Python.

I’d love to do this but at this point I’m not sure there’s going to be any benefit to it. In fact, it might just clutter things up. I guess there’s just no way of getting around C++.

Jhavna,
Ok, this is great. It’s exactly what I was needing. I hope you don’t mind but I’m going to go through each of the questions one by one just to help get it straight in my head as well:

How will your objects be stored internally, and how will they interface with the tools and other fucntions.

Ok, like I mentioned before, everything is essentially a node which is really just an instance of a class. All geometry nodes will have a basic world axis transform and a few state flags like visibility, select ability, as well as some render flags like hidden from rays, visible in alpha channel and so on. For the actual geometry, I was panning to do it this way: There’s going to be a list of points and a list of polygons. Each point has an ‘ID’ and a vector for x,y,z. The Poly list just holds arrays of point ID’s that make up each polygon. Things like vertex maps, morph maps, and clusters will be stored in separate lists and simply associate a value (or new vector in the case of the morph maps) with a point ID. My hope is that this might make it more efficient for things like searching and comparing because the ID’s are essentially pointers to the actual data. Any thoughts?

How are objects represented and managed on an individual basis and on a scene level?

I’m not sure. Do you mean, how they are represented in memory? I’m thinking of a linked list that holds the objects name and a pointer to the next one
Wait
I’m not sure about that. What are you thoughts on this?

How are they linked together?

Well, being nodes with inputs and outputs, I’m assuming that they can be linked in any way the user needs them to be. I’m planning on having a node view where each node can display it’s in and out ports. The ports will be linked together by some kind of linkage manager that handles what happens when a user does things like adding dynamic properties or skeletons and deformers. The link manager also takes care of adding and deleting controller nodes which are can be things like Curve based motion data, math operators, and simple functions. As far as how this is done internally, I’m assuming that whatever public methods are within the object are shown as available in and out ports in the nodal view. The user then has the option of dragging and dropping connections btween those ports. Any thoughts?

Will there be a master (root) object that will contain and manage the individual objects, or do objects manage themselves?

For the most part nodes will manage themselves but there will be a simple message passing API for them to communicate through. This is similar to the Maya Connections editor but easer to use because it’s done visually instead of through a lists.

What about viewport culling? Will you use BSP? or FOV?

Hmmm. I have to confess, I don’t know anything about this yet. Frankly, I thought viewport culling was a function of OpenGL? BSP… Are you talking about binary space partitioning? I thought that was what ray tracers do to help speed up the rendering? FOV? Feild of view? Hmmm.

Well, thanks so much for your help. This has been really great as far as getting me started. Again, I can post what I have of my technical overview so far if anyone is interested.

-=GB=-

Galen Beals,
Animator/Techincal Director,
Bent Image Lab

#7

Some classmates and I recently wrapped up an IK-like animation program for our final graphics project. It’s written in OpenGL and the cross-platform wxWindows API, in C++. The code’s a mess, since we had a strict deadline. To meet that deadline, I heavily relied on source code written by others to see how they structured their programs.

Consider downloading the source code to other people’s (successful!) 3D programs, and see how they represent data, and how they tie in the interface to the model/controller. Blender and Wings would perhaps be good candidates to look at. :slight_smile:

Good luck!

#8

Hello again. I’ll try to answer those questions for you…

RE: representing data
Sounds like you have done a fair bit of thinking on this already. But you didn’t seem to mention how you will index the points in your geometry. Remember, the order of points is important! Essentially, you are going the right way, but you want to also think about deformers and such. How are they going to be represented and hooked up to your geometry. Essentially, you’re going to create a entity relationship diagram. Any good software engineering book/C++ book should cover these if you need examples. Have a look in your local bookstore.

Re: storing objects
That kinda fit in with above. Other than a linked list, you could create more of a linked heirarchy using something like trees. So you can have a node with several children. This would allow for more interconnectivity and handling later on.

RE: handling and messages
Sounds good the way you are doing to do it…

RE: culling
yes, binary space partitioning (the tree structure would come in handy then) and field of view. They are not opengl based, for efficiency I highly recommend implementing your own!

I think a lot of info will come from your entity relation ship diagram…

well, I have to go… Hope that helps. Feel free to ask for more info. I may be able to point you into the direction of some books on software engineering/design if you like

#9

Originally posted by ngrava
As far as TK and QT go, I’m not sure yet. I’ve noticed that the connections for Python to TK are a lot simpler and easy to use then they are in C++. QT seems like a behemoth to me.

TK vs Qt vs any other toolkit…actually, my presonal preference is wxWindows, which in contrast to Qt is using native widgets and has a much less restrictive license.

Anyway, I was actually thinking of designing my own UI library in OpenGL! I’ve already seen one out there but it looks kind of ugly to me.

Blender is drawing its UI in OpenGL and it’s looking quite nice IMO. You should take a look at that.

I’d love to do this but at this point I’m not sure there’s going to be any benefit to it. In fact, it might just clutter things up. I guess there’s just no way of getting around C++.

The major benefit would be faster development and probably easier debugging. Python is at least taking the memory management burdon off your shoulders, plus there is already a great number of 3d related Python libraries you could tap into. In the past, I found the Python/C integration very easy to use.

Hmmm. I have to confess, I don’t know anything about this yet. Frankly, I thought viewport culling was a function of OpenGL? BSP… Are you talking about binary space partitioning? I thought that was what ray tracers do to help speed up the rendering?

I think what he meant was presorting the things you throw at OpenGL. If you pass your whole scene graph to OpenGL, things will beome very slow. If you visit a few game programming sites, they usually have good articles on how to determine what parts of the scene are in the visible range and which not - then you draw these in OpenGL which will do the detailed hidden surface removal.

#10

Compiled python scripts for handling all the ui stuff would take a lot of heat off your back, and allow for a lot more user customization. Maya handles about 90% of its UI through mel, meaning you can script just about anything, which is one of the great things about maya.

Now you’ve focused attention on something which I’d overlooked in your original post. Nodes. If you’re planning a node tree, then your problems become a whole lot more intense. I’ll take maya as an example.

Maya’s DAG and DG structure (if you don’t know what these mean, it’s time you started reading up on these terms now) is an incredibly complex beast. Maya uses lazy evalutation implemented by a “pull” method using the concept of dirty plugs.

i.e. every plug on a node has a dirty flag (actually it has several different dirty flags, but that’s not important now) which is set every time its input changes. A node is not re-evaluated until its output is requested, at which time Maya propogates a compute request upstream to all the nodes upon whose outputs the node to be re-evaluated’s outputs depend.

This is the basic concept, but Maya employs many tricks to make sure it only has to do as little work as possible.

What I am trying to impress upon you is that if you plan a node-based solution, you’re going to have to deal with this incredibly nasty algorithmic problem.

As for the opengl ui idea - i’m not sure it’s that great an idea. By all means handle any scene graphs etc with opengl, but keep the main window ui stuff on the cpu. You don’t want your ui to be eating up gpu cycles when a user’s trying to manipulate a heavy scene.

#11

Compiled python scripts for handling all the ui stuff would take a lot of heat off your back, and allow for a lot more user customization.

This is a great point and let me complicate things alittle more for you. ANother method of doing this is by using XML to describe the layout of the GUI and then using python to actually interpret and display the GUI. Skinning, baby. While not high on the must have features list its a great case in point of pre-planning for it as opposed to having to re-write everything later.

This brings me to a very important topic. KEEP THINGS SEPERATE!!! Do not mix data handeling with gui or math fxns or image handeling ect… This is a very important thing keep your data objects in one module, the gui in one module, your math, your image handeling, your tools, ect all seperate. That way when you need to make changes or even trash whole sections you don’t have to untangle the mess. Trust me this is a very important topic most people never get and debugging and future enhancements become a major battle.

#12

Oooo yes… This is cool. By the way, I’m calling the app Oasis Animator. Here we go:

SpriteGF,
That sounds great. I just had a look at that page and actually, it sounds pretty interesting. I’d love to have a look at the source. I’ve looked at Blenders IK source but to tell you the truth, I can’t seem to make heads or tails out of it. Which brings up something I find very confusing: Often times people split up there projects into so many separate files that it become very difficult to cross reference things and keep track of relationships. I’m not sure I understand the benefit of this. I guess, if you writing something in flat C, it can provide a sort of encapsulation and privacy. But to me it doesn’t make sense in and object oriented design since classes inherently provide this. Anyway, yes I have been looking at other people’s code but again, Blender seems to be the only one that‘s complete enough and that‘s hasn‘t been doing me much good. :slight_smile: Does anyone else have any other examples?

Jhavna,
RE: representing data, Yep your right, I haven’t given much thought to how deformers will interact with points. I have to confess that at this point I haven’t a clue. Perhaps, when you assign a deformer, references (pointers) to the points (maybe even just the point ID’s) that are closest to it or enclosed by it, are copied into an array that’s stored with the deformer (Basically, a vertex map). When you evaluate the deformer, the new positions of the points are calculated and thus sent back to the model. This is just my first guess off the top of my head so I’m sure there’s a better way to do it.

RE: Relationship diagram, I need some help on this. Do you know of any examples in books of on line?

RE: Sorting objects, You know, I was kinda thinking about trying to do this without a hierarchy. I know that might seem crazy but I’ve been thinking about how, in a lot of cases, hierarchy can actually be restrictive. And, it might actually help to have something like a DAG where hierarchy can be dynamic and implied. It might be an interesting experiment and offer some new possibilities. One of the areas I’m thinking that it might come in handy is with what I’ve been calling “bi-directional IK“. This is where you have the option of rotating from ether end of the bone or chain. Again, I haven’t been able to give real mechanics of this much thought and I’m not at all sure that it would work but I’d at least like to look into it. I have this book by Robert Sedgewick called “Algorithms in C++” that’s just a wealth of sorting algorithms. Maybe I can find something in there to support my theories. On the other hand, I might just mess up the very foundations of matrix transforms and I’ll have totally screwed myself. I’m interested in hearing other people’s opinions on this. Has anyone ever heard of doing something like this?

RE: Culling, (thanks to Stew as well) Oh yes I see what you mean. I guess you can see where this is all still a bit fuzzy to me. :wink: So I have to sort the polygons and throw out the ones that the camera can’t see and then send them to OGL. Ok, got it. There are so many hidden surface removal algorithms out there. Has anyone ever done a good comparison? This is one of those areas that I’m not very interested in because it borders to closely rendering which I’m trying to stay away from. It’s so subjective and to me the only reason I would want to make a renderer is if I had something new to offer (shadow volume based radiosity anyone?).

Stew,
I’ve done a little wxWindows. There’s a nice Python implementation. I think I’m going to need to post my UI mockup so you guys can see what I’m thinking of. Basically, my theory has always be that the current standard in windows UI design doesn’t have much to do with 3D programs. To me, (and this is where I can get pretty opinionated) the UI to a 3D program needs to be treated like a targeting system of a fighter jet. You don’t want panels floating all around while your trying to do fast on-the-fly precision work. So, for the fighter pilot, they came up with the HUD. This is similar to how I want to treat this. Hmm, I don’t think I can avoid going into detail here so bare with me: The Main UI looks like this:

Sorry for the long load time
Ok, this just a mockup. A lot of things will probably change once I find out just how difficult this is actually going to be. But the idea as you can see is to be able to show as much of the 3D view as possible. Let me just do a little explaining: The floating menu is my version of marking menus. You can lock them down by hitting the little circle on the left edge of it. Once you do that they become transparent. The Panels to the right and left (Properties and List views) slide in and out of view from there respective edges of the screen. You can of course lock them in place but then things will probably get all cluttered up again like they are here. :slight_smile: The timing editor (just above the timeline) will need to be popped with the mouse in order to make it come up by hitting the little arrow. You can have as many timing channels open as you like. I just stuck one in there for the heck of it and also to show how it’s main function is just to help control ease in and out and let you move key frames around. Modules to the right, selection mode to the left and that’s about it. One important thing that’s missing is the node view. Just imagine the 3D view darkening and a bunch of inter connected nodes (boxes) overlaid on top.
As you can see, there’s a lot of transparency going on there. Also, there’s no adhesion to the windows standard. The top of the window will have a title and menu bar with things like File, Edit, View, Options and Help. But that’s it as far as that’s concerned. So, my question is this: Can wxWindows do this sort of thing? With Python?

Playmesumch00ns,
RE: Python and C++, Hmm. Well, maybe I will do this
I’d certainly feel more comfortable with Python. I guess this issue for me is that I don’t have a clear delineation in my head about what can be Python and what has to me C++. Obviously, anything that does matrix math, deformations, IK and physics
I’m not really going to be doing that much OS specific UI stuff. A few files requesters, some menus, the main window
Hmm, maybe I can do the OpenGL handling in Python?

RE: Nodes and DAGs, Wow! That’s great, I had no idea that was what was going on in Maya. I’m sure it’s going to be nasty as hell but I think It’s going so worth it in the end. If I can pull this off, it’s going to be like Houdini meets Maya meets the old TDI. I like Houdini for the way it does nodal stuff but it’s way to complex to be used by average people. Maya on the other hand doesn’t give the user enough straight forward control. I’m planning on doing all the adding and deleting and connections of nodes auto automatically in the background but still let the user mess with it if they want. By the way, DAGs (directed acyclic graphs; I had to look at my Segewick book to find that out) are pretty intense. I’ll have to do a lot of reading up on them. The concept of setting dirty flags for evaluation is exactly what I was thinking of, but I hadn’t really thought it out that far. I would imagine that it would wined up being complex whether or not things where represented as nodes or not. Right?

RE: OpenGL UI, Ok so then how would I handle the transparency and anti aliasing efficiently enough with something like a UI kit? I guess I’m just asking the same question over and over again. Sorry about that.

Aurora,
RE: Keeping things separate. Oh, I definitely wasn’t being very clear there. When I said that some nodes would have UI code in them, I meant that they would just be calling the built in widgets that I had already built. The UI code would be separate from the calculation code within the node. If you think of it as nodes being plugins then it makes more sense. All of the interface stuff is handled with in the core app. The node just tells the app what features it has and the app builds the GUI. One thing I’ve really come to hate though are plug in API’s that give the developer enough tools to really make the plug in as useful as it could be. I want to be able to do things like create my own special object or some funky manipulator form within the node and not be restricted by the tools that the app provides. Does this make sense?

Ok, this wraps up another addition of “Yes I’m a lunatic for trying.” See you all soon. And thanks for all the great help you guys have given me. My brain has definitely been on overdrive today and that a good thing!

-=GB=-

Galen Beals,
Animator/Techincal Director,
Bent Image Lab

#13

Is the weekend over already? :frowning:

Ok, here’s some links for the entity realtionship diagrams:

http://www.umsl.edu/~sauter/analysis/er/er_intro.html
http://www.powells.com/cgi-bin/biblio?inkey=4-0201571684-4&partner_id=26556 (book on UML)
http://www.nmt.edu/tcc/sa/erd_how.html
http://www.smartdraw.com/specials/softdesign.asp?id=12079 (design software)
http://www.diagramstudio.com/entity_relationship_diagrams.htm (more software)
http://www.busadm.mu.edu/~culep/126matl/erdmodbw.ppt (a ppt file on the subject)

there is so much more… this search term should help you out aswell :slight_smile:

RE: organisation
Well, one thing I would like to say is: even in Maya, it’s not a linear structure. If you look at certain examples, you will have DAG paths. That is, you have two objects called ObjectA, but each is reachable via a different path, that’s how Maya distinguishes between the two. I won’t say that you won’t get away with using a list type struct, but it may make life easier if you use a tree… but that’s your call… after all, it’s you app :wink: You may also want to look into abstract data types for more info storing and organising data…

RE:Culling
Well, culling is important in the modelling viewport. Imagine you are modelling something with several thousand polys, and you rotate the polys (or verts) out of view. You don’t want to pipe those down the pipeline aswell.
That’s where a tree would come in handy you see. If a node can’t be seen, that means it’s children can’t be seen either, and you can stop checking at that leaf of the tree and not bother doing cull checks on its children. It’d make it more efficient… As for culling stuff, I think a viewport culling system is easiest. Create a frustrum for the persp viewport and check if verts or polys lie inside that frustrum. If the test is positive, then draw them, otherwise don’t. For some BSP and frustrum culling reading and examples, have a look here http://www.gametutorials.com/Tutorials/opengl/OpenGL_Pg5.htm
There’s examples of frustrum culling and Octree… Hope that helps… It’s in OpenGL BTW…

I think you have a fair bit to read there… enjoy :wink:

#14

Just wanted to say that I’ve just read through this thread, and, while it’s not me doing it, it’s got me really buzzing about this project - I’m going to be following it closely, and will offer advice in any area that I can (although I’m not convinced that there are any areas that there isn’t someone else here who knows more than me about…)

It’s fascinating seeing the hurdles that you’re going over even at this early stage…

One thing that I would suggest, with the plugin thoughts, is give the user a plugin API for UI widgets as well as internal workings…

One thing that I was trying to do in Maya about 6 months ago was get a custom AE controller for a node that I had written, but I only seemed able to get the standard ones…

Shake, however, handles this really well - as of Shake 3.0, the SDK allows you to write you own UI Widgets in OpenGL that you can connect up to attributes in your node. This is a completely seperate class of plugin from the normal node, so the code it kept completely seperate…

I think this kind of thing gives the plugin-writer so much more control over how the user interacts with their plugin…

The other thing that Shake any Maya both do is allow writing of on-screen controls - I can’t remember what Maya calls them (you know… the control that appear at the object when you’re doing something…) but Shake (again, as of 3.0) has the ability to write a custom overlay plugin that will draw on-screen whatever you want to control the attributes of your node…

#15

Originally posted by ngrava
Ok, got it. There are so many hidden surface removal algorithms out there. Has anyone ever done a good comparison?

Visit game programming sites, they usually have good resources on that subject.[b]

This is one of those areas that I’m not very interested in because it borders to closely rendering which I’m trying to stay away from.[/b]

Depending on what my schedule looks like in a few months, I might jump in here.

So, my question is this: Can wxWindows do this sort of thing? With Python?

Should be possible, if necessary subclass some of the wx controls. Even if you use only custom wx widgets, you still can use the event handling. Writing your whole UI toolkit from the scratch is a huge undertaking that’d I’d avoid where possible.

I’d certainly feel more comfortable with Python. I guess this issue for me is that I don’t have a clear delineation in my head about what can be Python and what has to me C++.

I’d say go with Python wherever possible and do only those things in C++ that will really profit from it. Maybe it’s the best to start in pure Python and use C++ only when you hit performance bottlenecks.

Hmm, maybe I can do the OpenGL handling in Python?

IIRC wxPython has a OpenGL canvas widget.

#16

Originally posted by JhavnaRE: organisation
Well, one thing I would like to say is: even in Maya, it’s not a linear structure. If you look at certain examples, you will have DAG paths. That is, you have two objects called ObjectA, but each is reachable via a different path, that’s how Maya distinguishes between the two. I won’t say that you won’t get away with using a list type struct, but it may make life easier if you use a tree… but that’s your call… after all, it’s you app ;)You may also want to look into abstract data types for more info storing and organising data…

Well, this is all very true. Yeah it‘s going to have to be some kind of tree. I was just wondering how other apps who don’t collect there data as nodes do it. And, really when you think about it, making it node based doesn’t really change anything; you still have to have a speedy structure of some kind under the hood. Right? I mean, It’s really just a way of specifying it’s external representation. I’m thinking that under the hood the only real difference that I can see, is that it allows for more non hierarchical connectivity. At least, that’s how it seems to me. I may be off on this. Making everything a black box object should make things more efficient and less interdependent.

I also wanted to say that I have an issue with trying to copy Maya to much. It’s not really the speediest app on the block. And, I would definitely question the methods of anyone who was involved in writing Alias Power Animator. :wink: That program definitely had issues with data organization.

RE:Culling
Well, culling is important in the modelling viewport. Imagine you are modelling something with several thousand polys, and you rotate the polys (or verts) out of view. You don’t want to pipe those down the pipeline aswell.
That’s where a tree would come in handy you see. If a node can’t be seen, that means it’s children can’t be seen either, and you can stop checking at that leaf of the tree and not bother doing cull checks on its children. It’d make it more efficient… As for culling stuff, I think a viewport culling system is easiest. Create a frustrum for the persp viewport and check if verts or polys lie inside that frustrum. If the test is positive, then draw them, otherwise don’t. For some BSP and frustrum culling reading and examples, have a look here http://www.gametutorials.com/Tutori.../OpenGL_Pg5.htm
There’s examples of frustrum culling and Octree… Hope that helps… It’s in OpenGL BTW

Excellent! This is great. I just looked at those tutorials and they look very cool. This site is a wealth of information. Simple things like the Obj loader. I’ve been thinking about how to do this but this is way easer then what I came up with. I never thought of using a BSP tree for culling! I’ve always thought of it as a way for a Ray tracer to skip some spatial calculations and get to the surface faster so it can start doing hit tests. This is really great stuff and has cleared up a lot of little details for me. Thanks a lot!

Originally posted by Hugh Just wanted to say that I’ve just read through this thread, and, while it’s not me doing it, it’s got me really buzzing about this project - I’m going to be following it closely, and will offer advice in any area that I can (although I’m not convinced that there are any areas that there isn’t someone else here who knows more than me about…)

Don’t worry about that. The point is that this is a beginners project. I’m having to figure out everything from square one. Well, not exactly, But there’s a huge amount is information that I don’t know. But I figure, this is a great way to learn. You know? Take chances, make mistakes, get your hands dirty and that kind of stuff. And, even if I fail to complete the project, imagine the trail I’ll leave for others who are interested in this sort of thing. :slight_smile:

One thing that I would suggest, with the plugin thoughts, is give the user a plugin API for UI widgets as well as internal workings.

Yeah this is exactly what I was talking about when I was referring to plugin API’s that are to restrictive.

what Maya calls them (you know… the control that appear at the object when you’re doing something…) but Shake (again, as of 3.0) has the ability to write a custom overlay plugin that will draw on-screen whatever you want to control the attributes of your node

“Manipulators”, Yes, this is exactly what I was thinking! I also had an idea where you could load up a model and assign different command to vertex groups be executed when you click on them. So for instance, say you make some rotate manipulator in Wings, the X plane circle would be “VertexGroupX”, Z would be “VertexGroupZ” and so on. Then in Oasis, you could assign a command to those groups like “VertexGroupX = self.rotatex” and make the object a simple rotate manipulator.

Originally posted by Jhavnaquote ngrava:

This is one of those areas that I’m not very interested in because it borders to closely rendering which I’m trying to stay away from.

Depending on what my schedule looks like in a few months, I might jump in here.

Sure! That sounds great. I hope I’m far enough along by then. I should explain that another reason I’m leaving out the renderer is that I want to help support this whole new idea that people should pick there render first then pick an app that supports it. The final output is all people wind up seeing in the end. I also want people to try using it for serious production. In my experience, the main thing that hampers people while doing this is issues with rendering. Take Maya for example, No one who uses it for feature work uses the built in render for final output. They always use PRRenderMan or some custom joby. This is exactly how I want people to think of Oasis. It’s just a part of your pipeline. It’s going to support a number renders right off the bat. All the free Renderman renders, PRMan it’s self, VRay, Brazil, maybe Mental Ray (it’s going to have to get a lot faster) and whatever else comes along.

I’d say go with Python wherever possible and do only those things in C++ that will really profit from it. Maybe it’s the best to start in pure Python and use C++ only when you hit performance bottlenecks.

Yeah, I’m just now starting to form a picture in my head of what this all looks like. I ran into this page that explains how to derive Python classes from C++ libraries: http://www.python.org/workshops/1995-12/papers/ahlstrom1.html. So, I’m getting closer to understanding. The one thing I’m worried about is pointers. There’s aren’t any in Python
Usually I haven’t really had any need to use them in my personal projects but all of a sudden with 3D, pointers become a necessity. You can’t keep loading data onto the stack to change it and save it back. You need to act directly on it. That’s where pointers come in. So, is there some way to simulate pointers python? I know other languages have reference types. Does Python have anything like that? I’m I missing something here? Please tell me if I’m making a big deal out of nothing. :wink:

quote ngrava:

Hmm, maybe I can do the OpenGL handling in Python?

IIRC wxPython has a OpenGL canvas widget.

And

Should be possible, if necessary subclass some of the wx controls. Even if you use only custom wx widgets, you still can use the event handling. Writing your whole UI toolkit from the scratch is a huge undertaking that’d I’d avoid where possible.

This is a great idea cuz it will make that part of the program way more portable. There are two different things that I haven’t been able to find out just yet: 1) Does wxWin handle anti-aliased text. This is a big one. And 2) Does wxWin handle transparency. Not as big of a deal since I’m still leaning toward an OpenGL approach.

Thanks again guys!

-=GB=-

Galen Beals,
Animator/Technical Director,
Bent Image Lab

#17

Glad it helped… If you need more info, do check out www.gamedev.net and www.flipcode.com, both are game sites, but graphics is graphics…

I didn’t mean to say you should go the Maya way, I was just using that as an example. I was only trying to provide you with an example of sorts. It’d probably be wise to mix the use of tree and list… depending which is more appropriate for given task. BTW, http://www.stlport.org/ provides an improved implementation of the STL libs. They’re faster and more stable than the Microsoft STL libs… Just in case you wanted to use STLs in your app to start with…

If you need a decent host for your project, you may want to try www.sourceforge.net However your project will have to be open source. Not sure if that is something you want. But the plus side of it is, you get full CVS, telnet access to your account, project management, webspace and lots of other stuff (well, you can check it out yourself I guess), all for free.

One more thing about culling. If you are going to use tree based culling, then you will have to be careful how you organise your tree. If a node isn’t visible, then neither will its children be visible. Hence, all children have to lie within the boundry of the parent… just thought I’d mention that. For example, if a tentacle is a child of a head say, then if the head isn’t visible, then the tentacle won’t be either, even though it may be in the viewport… I guess that’s obvious, but I thought I’d mention it anyway. It’d be good if you have the geometry as a parent and modifiers as children, then your app wouldn’t have to do the math when the object goes out of view… It might be a good idea to make the culling boundries slightly larger than the viewport in that case, as you don’t want the object to rotate into view and then pop to its modified state :wink:

Well, I am looking forward to seeing/hearing your progress. It’s an exciting project for sure! And I am sure everyone who has contributed to this thread will be glad to assist whenever they can… right guys? :wink:

BTW… the preliminary GUI looks reall nice already!

oooh… it’s nearly Xmas! :bounce:

#18

Originally posted by Jhavna
Glad it helped… If you need more info, do check out www.gamedev.net and www.flipcode.com, both are game sites, but graphics is graphics…

Hey Jhavna,
Yeah, those are both really great sites. They’ve been a lot of help so far. thanks!

I didn’t mean to say you should go the Maya way, I was just using that as an example. I was only trying to provide you with an example of sorts.

Oh sorry about that. I didn’t mean to say, “Hey stop talking about Maya!” or anything. Actually, I’m really quite interested in how other programs work. Especially Maya. I just said that because I’m not sure that the way they do it is best or anything. I don’t know what the best way is anyway. I’m just messing about myself. Please don’t hesitate to draw comparisons, it’s really quite useful.

It’d probably be wise to mix the use of tree and list… depending which is more appropriate for given task. BTW, http://www.stlport.org/ provides an improved implementation of the STL libs. They’re faster and more stable than the Microsoft STL libs… Just in case you wanted to use STLs in your app to start with…

Cool! I’ll download that right away. Does it work with VC6? I’m in need of a refresher on C++ so I bought myself a Christmas present the other night. I was at Powell’s technical books (an excellent book store here in Portland, Oregon by the way) and picked up a copy of “An Introduction to Object-Oriented Programming in C++ with Applications in Computer Graphics” by Graham Seed (isbn 1-85233-450-9 incase anyone’s interested). It’s really great because the whole time it’s teaching you C++, it’s showing you examples in CGI. It also includes a bunch of STL along the way. So far I’m loving it.

If you need a decent host for your project, you may want to try www.sourceforge.net However your project will have to be open source. Not sure if that is something you want. But the plus side of it is, you get full CVS, telnet access to your account, project management, webspace and lots of other stuff (well, you can check it out yourself I guess), all for free.

You know, I just don’t know about this. On the one hand the program is going to be free so why not do it the open source way. On the other hand, there may come a day when we want to make a little (most likely, very little) money from it and I can’t very likely do that if it’s open source. I just don’t know. I’m planning on making an extensive SDK for it so it’s going to be very open in that respect… I guess I just don’t know what’s going to come out of this. If it turns out to be just a hackish little program that can barely stand on it’s own two feet, then by all means, it should be open source. And I can always go the Blender way and make it open when that times comes. I hope that doesn’t come off sounding selfish… I guess it is a little.

One more thing about culling. If you are going to use tree based culling, then you will have to be careful how you organise your tree. If a node isn’t visible, then neither will its children be visible. Hence, all children have to lie within the boundry of the parent… just thought I’d mention that. For example, if a tentacle is a child of a head say, then if the head isn’t visible, then the tentacle won’t be either, even though it may be in the viewport… I guess that’s obvious, but I thought I’d mention it anyway.
actually, this is great. This is exactly the sort of stuff I need to be thinking about. So, the tree based calculation can actually be problematic in this case. Either that or you have to just keep going down the tree and checking. Something else I was thinking about too: What about z-sorting? For some reason it seems faster when I look at the algorithm. I mean, doesn’t it seem like a waste to build this huge tree for every frame? Am I looking at this from the wrong angle?

It’d be good if you have the geometry as a parent and modifiers as children, then your app wouldn’t have to do the math when the object goes out of view…

again, this is something else I hadn’t thought of. Interestingly enough, I was making up a feature/node/class diagram and that’s how things are looking anyway. Deformers are added down the chain from the actual mesh node instead of them being internal to mesh class. I’m thinking about making it so that they inherit the mesh data and can do calculations directly on it through pointers.

It might be a good idea to make the culling boundries slightly larger than the viewport in that case, as you don’t want the object to rotate into view and then pop to its modified state :wink:
Now that’s just silly. I can see the mesh popping it head out from the edge of stage right waving to someone in the audience. “Hi mom!”

Well, I am looking forward to seeing/hearing your progress. It’s an exciting project for sure! And I am sure everyone who has contributed to this thread will be glad to assist whenever they can… right guys? :wink:

I hope so because I obviously need all the help I can get. :smiley:

[b]BTW… the preliminary GUI looks reall nice already!

oooh… it’s nearly Xmas! :bounce: [/B]

Thanks so much! I just made it in flash the other day. It’s pretty much exactly how I want it to look. You know, looking at it just now, I realize that there’s a few errors in it; the Setup module is selected but the timeline is visible. This wouldn’t be the case since Setup, as a mode, has no time base to it. It’s always in the default pose. You can still move things around to test them but they don’t stick unless you explicitly tell them to. This allows you to go back and change things in the setup after you’ve begun animating. It’s kind of like how Hash’s Animation:Master has a bones mode that’s separate from everything else. At least, that just the idea so far. The other thing is that you would at least see the main skeleton node in the list view. Oh well. It’s just a mock up right?

Ok, that’s enough for now. Thanks again for all the help!

-=GB=-

#19

MAN! These posts are getting huge!

I had another idea just tonight that I put on my silly -“gee wiz” list. (warnning:Feature crawl) I’m calling it the “Reference panel”. It shares space with the list view. Basically, the idea comes from working in productions where I’m always wishing I had some kind of window that held pictures or sketches and things I needed to refer to often while animating. Even better would be the ability to change the pictures on a frame by frame basis. So, I could make little animatics that change while I was moving the frame slider. And, even better then that… What if it had some elementary drawing ability?! I could do a quick thumbnail animatic of what was to happen in the scene before I even started to animate. Just to test out the timing! It definitely won’t get worked on until I have the rest of the program fleshed out though. But I thought I’d mention it just to get it out there so I wouldn’t forget. :slight_smile:

-=GB=-

Galen Beals,
Animator/Techincal Director,
Bent Image Lab

#20

You might be interested in looking at some of the work done by Eskil Steenberg (sp?) on the next generation of Blender. He made a graphical network protocol (verse) that stores and transmits subdivision meshes, bitmaps, and animation data. The goal was to separate the data storage from the data manipulation in the program.

He also wrote some custom OpenGL UI display libraries that could probably be modified to your interests. It’s all open source and exists in a downloadable form. His spelling is a bit odd but the code seems to work. Connector is the program that is probably the closest to what you are trying to do; it might be worth looking at. It would be nice to have several people collaborating on one project that really goes somewhere instead of 20 tiny projects, and if your primary interest is in the UI design instead of back end data storage this might save you months/years of time.

http://www.blender.org/modules/verse/

Thanks,

Eliot