PDA

View Full Version : Where to start with BIG projects?


ngrava
12-19-2003, 06:27 AM
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

playmesumch00ns
12-19-2003, 09:27 AM
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!

stew
12-19-2003, 12:50 PM
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.

Jhavna
12-19-2003, 01:58 PM
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)

aurora
12-19-2003, 02:40 PM
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

ngrava
12-19-2003, 06:49 PM
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.;) 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! :)

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

SpriteGF
12-20-2003, 06:56 AM
Some classmates and I recently wrapped up an IK-like animation program (http://inst.eecs.berkeley.edu/~schan/finalproject/) 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. :)

Good luck!

Jhavna
12-20-2003, 07:52 AM
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

stew
12-20-2003, 11:39 AM
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.

playmesumch00ns
12-20-2003, 01:31 PM
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.

aurora
12-20-2003, 02:55 PM
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.

ngrava
12-21-2003, 07:38 AM
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. :) 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. ;) 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:

http://www.cybcon.com/~galenb/Oasis_Moskup.jpg

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. :) 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

Jhavna
12-22-2003, 09:17 AM
Is the weekend over already? :(

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 (http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=entity+relationship+diagrams+-database&btnG=Google+Search) should help you out aswell :)

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 ;) 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 ;)

Hugh
12-22-2003, 10:04 AM
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...

stew
12-22-2003, 10:32 AM
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. 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.
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.

ngrava
12-22-2003, 09:09 PM
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. ;) 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. :)
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. ;)
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

Jhavna
12-23-2003, 09:03 AM
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 ;)

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? ;)

BTW.. the preliminary GUI looks reall nice already!

oooh.. it's nearly Xmas! :bounce:

ngrava
12-24-2003, 09:44 AM
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 ;) 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? ;)
I hope so because I obviously need all the help I can get. :D
BTW.. the preliminary GUI looks reall nice already!

oooh.. it's nearly Xmas! :bounce:
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=-

ngrava
12-24-2003, 09:50 AM
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. :)

-=GB=-

---------------
Galen Beals,
Animator/Techincal Director,
Bent Image Lab

emack
12-24-2003, 03:05 PM
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

elam
12-24-2003, 08:21 PM
If you check out Verse, you might also want to play around with his Sub-D modeling program, Loq Airou, which uses the Verse protocol(You need SDL (http://www.libsdl.org/index.php) to run it).
It's fairly buggy, but it runs, and has the same ideas you have in terms of gui design in that there are no floating panels. Its just a canvas with pop up menus. Very minimalist. Very trippy.
http://68.41.119.123:3280/lou.png

Apoclypse
12-26-2003, 07:53 PM
No body can force you to, GPL the thing ( though if you go with the BSD licensing scheme, your app can be open source and then later on you can change it to a commercial one or something like that) However it has always been my dream to have a fully professional "maya-like" 3d app come out of the GNU/GPL free for all users without restrictions or stunted functionality ( PLE and EXP). This to me is the future of 3d. If companies out there like discreet and alias keep taking out marginal upgrades with tacked on plugins, then the 3d community along with the gnu community will have to take charge.

I'm not advocating GPL, or trying to force you to make this an open source project. However the open source community can really help you in your cause and it is only fair if you are going to use open source software to develope you app.

Now let me explain what i mean by maya like. I don't mean a maya clone what I mean is a robust professional 3d program that can actually be used in production. Something that can be used to make the matrix or lord of the rings with results.

Oh and when you start the particle and dynamics system call me I have some ideas.

ngrava
12-26-2003, 10:55 PM
Originally posted by Apoclypse
No body can force you to, GPL the thing ( though if you go with the BSD licensing scheme, your app can be open source and then later on you can change it to a commercial one or something like that) However it has always been my dream to have a fully professional "maya-like" 3d app come out of the GNU/GPL free for all users without restrictions or stunted functionality ( PLE and EXP). This to me is the future of 3d. If companies out there like discreet and alias keep taking out marginal upgrades with tacked on plugins, then the 3d community along with the gnu community will have to take charge.
Yep, this is exactly what I intend on doing. Oasis Animator is going to be a free (most likely GPL or something like that) 3D Animation program for professional use. The part that I mentioned about some day selling the software is based on the idea I have to make an Oasis "Complete" version much latter in it's life. As stated before, Oasis Animator will have no modeler but instead rely on the Obj and Lwo model formats and, it will have no built in renderer but instead rely on the renderman standard (of which there are already 4 free ones) renderers as well as some other potentials. This is actually more of a professional approach to production since most effects and animation studios take a pipeline approach to projects where data is pushed through custom and off the shelf software and usually ends up in PRRenderMan in the end anyway.
The "Complete" version will most likely have
-A modeler based on some wacky ideas I have about SubD's and spline modelers (That's all I can say for now). Major highbred.
- A huge, very high quality renderer that's optimized for film production.
-A rewritten optimized core. This is because you can expect the first version of Oasis to be a bit clunky. But, by the time I'm ready to make "Complete", I'll hopfully have learned a thing or two. ;)
By the way, you mentioned taking on plugins for releases. Well, that's exactly what Oasis will be doing. You see, Oasis is just the core application. Just about all of the major features are going to be built into plugin DLLs/SOs called Nodes. Hope that doesn't piss anyone off or make them feel like they are being cheated. The upside to this is that it makes Oasis much more open to custom development. You'll be able to modify, creat or simply customize features to you hearts content.
I'm not advocating GPL, or trying to force you to make this an open source project. However the open source community can really help you in your cause and it is only fair if you are going to use open source software to develope you app.
Yep, and that's exactly the reason I'm having trouble deciding.
Now let me explain what i mean by maya like. I don't mean a maya clone what I mean is a robust professional 3d program that can actually be used in production. Something that can be used to make the matrix or lord of the rings with results.Heay, you read my mind... Or posts. ;)
Oh and when you start the particle and dynamics system call me I have some ideas. I believe (and correct me if I'm wrong) that Oasis will be the first 3D animation program to have real-time dynamics and collision detection. The will be active during animation so as your animating you can push objects around or they can push you character around and stuff like that. It's going to be really cool and pretty easy to program because it just uses simple game engine type collision detection. This is going to be one of the main features and I believe that if I do it right, you'll see it in other 3D programs as well. But yeah, I'll contact you when I start.

Thanks for the comments and suggestions! Keep them coming,

-=GB=-

---------------
Galen Beals,
Animator/Technical Director,
Bent Image Lab

Tripdragon
12-27-2003, 06:11 PM
Dude, if you can make it work on a Mac OSX I am happy ... ^v^ :D:beer: :beer: :beer:

ngrava
12-28-2003, 01:03 AM
Yes. A good friend who is an excellent programmer has already offered to do the porting. So, yes there will definitely be an OSX version. And, even if that doesn't work out for whatever reason, I plan on using a cross platform library that supports OSX.

-=GB=-

Tripdragon
12-28-2003, 05:05 AM
Originally posted by ngrava
Yes. A good friend who is an excellent programmer has already offered to do the porting. So, yes there will definitely be an OSX version. And, even if that doesn't work out for whatever reason, I plan on using a cross platform library that supports OSX.

-=GB=-
Sweet ! Can't wait ... ^v^

Apoclypse
12-29-2003, 06:08 PM
I would have liked this to be Linux only ( linux needs more software, well not really but it needs more software that works) But I guess being open to more platforms will make your app more viable.

Apoclypse
12-30-2003, 04:31 PM
If you could please post the references that you are using I can better understand what you are doing. In other words what books and sites are you using and where can I find them. This is a subject I'm very interested in so expect me to post here frequently.

I will keep this thread alive.

ngrava
12-31-2003, 06:26 AM
OK, here's a sampling of the information that I've been culling from the net.

I've found that a lot of the game development sites seem to have a lot of really great tutorials and code chunks that have been
increadibly helpful. The funny thing is, a lot of this stuff is more relevent to an animation program. ;)

http://www.gdmag.com/homepage.htm
http://www.gamedev.net
http://www.flipcode.com
http://www.gametutorials.com/

http://panoramix.ift.uni.wroc.pl/~maq/eng/index.php
http://www.brockeng.com/VMech/IK/IKSG.htm
http://freespace.virgin.net/hugo.elias/models/m_main.htm
http://www.darwin3d.com./gdm1998.htm#3DIKSTUFF

I'll post some more latter

-=GB=-

Apoclypse
01-05-2004, 05:05 PM
Thanks man, what about books?

markyjerky
01-14-2004, 05:50 PM
Here's how I started a big 3D project ...

"Put one foot in front of the other ... and soon you'll be walking out the doooooo ooo oor."

I've got a very large and very contemporary 3D API that includes both a user interface sufficient to eliciting any typicial inputs from a 3D user and a very good API for manipulating a subclass of 3D objects ... that are Manifolds. I mean ... it's like Nendo and Wings3D ... but written in Java.

Go to www.ggaliens.com and follow the links. I need a partner on this project, someone to eventually succeed me as thae care-taker.

I'm suprised that no programmers have jumped in to stake a claim. It's a very RICH API. And the program does some very cool things.

There is also a forum that I have paid for.

Download the code and have a look around and ask me questions.

ngrava
01-15-2004, 12:20 AM
Ok, I was thinking about the whole idea of a bi-directional hierarchy. Iíve been looking at all sorts of different IK algorithms and none of them really support this idea. In fact, most of them are very hierarchy dependent. Then I came across something interesting. Spring systems. The idea is that you use particles connected by rods that can be ridged or flexible (the rods could even be splines!). The particles are the nodes at the joints and have physical properties. So essentially, when you grab a node you use a dynamic simulation to pull the other nodes around with it creating an IK like effect. Springs can be pretty uncontrollable so thereís going to have to be some very explicit constrains involved but I think itís a very workable solution that offers some new things that regular IK doesnít. For instance, skeletons constructed of springs have built in dynamics, motion can be dynamically distributed along a chain to the rest of the skeleton to simulate secondary motion, chains could be made to stretch without to much effort, and nodes can more easily be ďpinned/un-pinnedĒ or constrained over time. All, in all it looks like a very interesting solution. Best of all, it works really well into this whole idea I have about real-time collision detection and dynamics that are active while your animating.

The issue I have at the moment is figuring out how to transform a mesh based on the positions of the nodes.

What do you guys think of this? Any foreseeable issues?

-=GB=-

P.S. markyjerky, I downloaded the project files. It does look very interesting. Unfortunatly, I ruled out Java a while ago. Thanks for the heads up though.

Tripdragon
01-15-2004, 03:02 AM
Originally posted by ngrava
Ok, I was thinking about the whole idea of a bi-directional hierarchy. Iíve been looking at all sorts of different IK algorithms and none of them really support this idea. In fact, most of them are very hierarchy dependent. Then I came across something interesting. Spring systems. The idea is that you use particles connected by rods that can be ridged or flexible (the rods could even be splines!). The particles are the nodes at the joints and have physical properties. So essentially, when you grab a node you use a dynamic simulation to pull the other nodes around with it creating an IK like effect. Springs can be pretty uncontrollable so thereís going to have to be some very explicit constrains involved but I think itís a very workable solution that offers some new things that regular IK doesnít. For instance, skeletons constructed of springs have built in dynamics, motion can be dynamically distributed along a chain to the rest of the skeleton to simulate secondary motion, chains could be made to stretch without to much effort, and nodes can more easily be ďpinned/un-pinnedĒ or constrained over time. All, in all it looks like a very interesting solution. Best of all, it works really well into this whole idea I have about real-time collision detection and dynamics that are active while your animating.

The issue I have at the moment is figuring out how to transform a mesh based on the positions of the nodes.

What do you guys think of this? Any foreseeable issues?

-=GB=-

P.S. markyjerky, I downloaded the project files. It does look very interesting. Unfortunatly, I ruled out Java a while ago. Thanks for the heads up though.

ANYTHING I mean ANYTHING dynamic and new for IK chains is a welcome change. Just pull the hand and the entire body gets pulled would be soooo nice !

Please release test builds as soon as you can .

Tripdragon
01-15-2004, 03:07 AM
Originally posted by markyjerky
Here's how I started a big 3D project ...

"Put one foot in front of the other ... and soon you'll be walking out the doooooo ooo oor."

I've got a very large and very contemporary 3D API that includes both a user interface sufficient to eliciting any typicial inputs from a 3D user and a very good API for manipulating a subclass of 3D objects ... that are Manifolds. I mean ... it's like Nendo and Wings3D ... but written in Java.

Go to www.ggaliens.com and follow the links. I need a partner on this project, someone to eventually succeed me as thae care-taker.

I'm suprised that no programmers have jumped in to stake a claim. It's a very RICH API. And the program does some very cool things.

There is also a forum that I have paid for.

Download the code and have a look around and ask me questions.

And markyjerky the ONLY problem with nobody helping you with your stuff is because of your site. It looks to much like you did not put effort into it. That is all. I will gladly test it though and report back, but java is eeeeeeeviiiil

:p

markyjerky
01-15-2004, 02:51 PM
Well ... if Java is evil , doesn't that ...

Rule you out ?

I've been programming in many computer languages since 1980. That's a long time. I was not child programmer. I'm 38 years old.
I won't sugar coat stuff and try to toe a political line(s). I just tell it like it is ... as I've seen it. Java is not so great in its fundementals ... that's not what it's about ... it's about the Java tools as much as the language itself. C++ if fine by me too. I prototyped this app in C++ and then moved it to Java for portablity.

PCs are just too darn fast these days to be quibbling about anything less than an order of magnitude of performance difference between languages. Why ? Because the order of magnitude speed ups can be plucked like fruit from a tree in the realm of the virtual machine ... (and I don't mean JVM) ... I mean just in the software algorithms. They are not all written yet.

Java is PLENTY FAST ENOUGH for 3D.

If you guys need help ... let me know. Anc stop squabbling about what tools to use ... just get friggin' busy.

If anyone wants to help my pretty up my site ... that's a possibility too.

Good luck with you projects.

ngrava
01-15-2004, 04:16 PM
Originally posted by markyjerky
[B] I've been programming in many computer languages since 1980. That's a long time. I was not child programmer. I'm 38 years old.[/I] well, I'm 35. I haven't been programming that long at all. Started in 95 with C as a hobby and it's grown since then. Mainly LightWave's LScript and Python lately but I'm using C++ for Oasis. I've had to crack open a all the C++ books I had just to get started. ;)
PCs are just too darn fast these days to be quibbling about anything less than an order of magnitude of performance difference between languages. Why ? Because the order of magnitude speed ups can be plucked like fruit from a tree in the realm of the virtual machine ... (and I don't mean JVM) ... I mean just in the software algorithms. They are not all written yet.

Java is PLENTY FAST ENOUGH for 3D.
Easy there... To tell you the honest truth, and Iím not trying to be offencive here but, I've never seen Java be plenty fast enough for 3D. All the examples I've seen have been very weak. Maybe you're right though that it's got more to do with the algorithms used then the language.

To me, as far as speed is concerned, PC's are still not fast enough for what I want to do. I should point out that this is comming from a production oriented perspective where you have to through in everything you can to get the job done and still get more work afterwords. I want to be able to use Global Illumination, hyper-textures, high Stochastic sampling for Motion blur, depth of field, and anti-aliasing, real-time physics, collision detection etc, etc. I've been working in CG since 93 (as a professional animator and TD) and I've always had to settle for "Just OK". Maybe my standards are set to high but I feel like it's time to move forward and push the technology to the next level. I can totally understand wanting to use Java. I don't have any problem with Java. It's just that I need every little ounce of power I can get my hands on. One of the reasons for this is that I don't have time to try out every algorithm in the book. Using C++ will allow me a little slop when I neeed it.

If you guys need help ... let me know. Anc stop squabbling about what tools to use ... just get friggin' busy.
I am busy and I do need help. Here are some things I'd like to know:

- Do you see any issues with the spring system mentioned above?

- I'm trying to roll my own widgets and GUI in OpenGL. Any advice/ideas on how to do this effectively would be great.

- I need a good hit test algorithm for selection that has to run all the time. The UI is going to be very dynamic and highlight just about everything under the mouse. I tried the stencil buffer trick but it had issues with the way I'm drawing a perspective window and then a ortho view over the top of that. I'd like to use a ray-caster but I can't seem to find any info on building one. Any help would be greatly appreciated !

Thanks!

-=GB=-

StefanDidak
01-15-2004, 04:53 PM
Originally posted by markyjerky
Java is PLENTY FAST ENOUGH for 3D.


I also took my first programming steps in 1980 but a lot has changed since then. Enough has changed that there's hardly any parallel anymore given the overall increased complexity of software development.

If you're saying that managed code (either based on a VM or a CLR) can run just as fast, or faster, than lower level C++ code you're right... but it depends on the assumption of how well or how bad the lower level unmanaged code was crafted. Managed code can outperform badly written unmanaged code quite easily. But whether Java is fast enough for 3D is different yet again and seems universally not accepted as such when looking at how many commercial and how many in-house projects at various places do not make use of Java. There has been a substantial amount of interest in various aspects of 3D development using managed code but Java has clearly not been considered as an option.

I'm just telling it like it is... other than you I've seen nobody put Java to any practical use (yet). The conclusion that remains is that those doing development are not considering it as a viable technology at this time.

iC4
01-15-2004, 05:52 PM
ngrava:

just wondering which libraries do you use? opengl + ?. GLUT? GLT? CPW?

or just do you program just for windows?

I'm also at the beginning of my project and I'm not sure yet what do use.

ngrava
01-15-2004, 06:49 PM
Originally posted by iC4-
ngrava:

just wondering which libraries do you use? opengl + ?. GLUT? GLT? CPW?

or just do you program just for windows?

I'm also at the beginning of my project and I'm not sure yet what do use.


I'm just using windows API right now. I'll probably switch to GLUT eventually (or a C++ derivative) when I have some time to learn that. Since I'm making my own GUI in GL I don't need to worry as much about the cross platform issues just yet.

I was up in arms about where to start about two weeks ago. FLTK, wxWindows, others? I didn't know what to do. Then a friend (who will be doing the Mac port by the way) just laid it out for me a said, "You just need to get a GL window up and loading geometry in it for now." That's absolutely right. I just need to get started and quit deliberating. On top of that I realized that I'm not going to be needing any of the UI elements like Dialog Boxes and widgets that a kit would provide so the rest is all about event handling and file IO. Those issues can be dealt with a bit latter. For now, I'm just using the win API to build a window and the rest (so far) is all GL.

This isnít going to make things easer in the least bit. I have several daunting tasks ahead of me. I just need to stay focused and break everything down into manageable parts.

I'm not sure if that helps you at all but that's what I've been up to. ;)

Good luck,

-=GB=-

Apoclypse
01-15-2004, 10:10 PM
I know you are set on doing the GUI in OpenGL, but I really don't see it as a viable solution. What Happens to those user ( since your software will be free this will be more than likeley) who don't happen to have a graphics card or are using an old ATI Rage Pro for their graphics card ( which if I'm not mistaken only does DirectX) how will they be able to use the program. Performance on these machines will probably already be slow, so having the gui ( which in this case will be handled through the software) will be way too slow.

You have to realize that when a program like yours is free odds are there is some guy with a 233 mhz computer and a 6 gig hardrive who wants to run your program becuase it is in his price range ( free).

markyjerky
01-15-2004, 10:17 PM
(1) Java is fast enough to capture mouse movements, display button, display tables, and to manage OpenGL Display Lists.

(2) Use Display Lists carefully and the High Level language binding C vs Java just does not matter at all. Period.

(3) If you have some kind of memory intensive call that really needs to be done natively ... then use Dirty java. Code the stuff in C and bind it to java. It's easy and worth learning.

(4) Check out the speed of Manifold Lab. It's written in Java. I compared it to many other C and Java apps ... and it runs like a Native app. It should ... it's about the display lists.

Don't cave in and use some second rate GUI builder. Java/Netbeans rules. Or use Java Eclipse.

I never spend any time on GUIs ... they just "fall out" of My Java NetBeans as should be the case with any good GUI builder.

iC4
01-15-2004, 11:24 PM
Originally posted by Apoclypse
I know you are set on doing the GUI in OpenGL, but I really don't see it as a viable solution. What Happens to those user ( since your software will be free this will be more than likeley) who don't happen to have a graphics card or are using an old ATI Rage Pro for their graphics card ( which if I'm not mistaken only does DirectX) how will they be able to use the program. Performance on these machines will probably already be slow, so having the gui ( which in this case will be handled through the software) will be way too slow.

You have to realize that when a program like yours is free odds are there is some guy with a 233 mhz computer and a 6 gig hardrive who wants to run your program becuase it is in his price range ( free).

I read the whole thread some time ago, and if I remember correclty it's not planed to be free?

And if you are programing a 3d animation program you can't take care of guys with an 233mhz computer....they should better play tetris than making 3d animations.

ngrava
01-16-2004, 12:16 AM
Oh god! Stop with the Java stuff! Enough programming religion. Please. Youíre right, using Java to manipulate OpenGL is just fine. However, Oasis is going to have to do a lot more then that. Yes, you can easily bind C to Java to C and C to Python and Lua and Io, etc, etc. However like I said, I made a decision a while ago that I wasnít going to mess around with that just yet. Maybe latter Iíll add a way to bind in scripting languages.

ďI never spend any time on GUIs ... they just "fall out" of My Java NetBeans as should be the case with any good GUI builder.Ē

If you go back and read the rest of this thread, youíll see that GUI programming is what I like doing the most. I have very specific ideas about UI design.

Apoclypse,
About lowest common denominator:
Thatís a very good point and something I hadnít thought of until you mentioned it. I know youíre absolutely right but thereís a part of me thatís really just writing this program for myself. Also, I donít see anything wrong with defining the minimum system requirements. Just as long as you do so up front.

The other thing is that Oasis is actually going to be aimed at a higher end user. I have no intention of ďteachingĒ people who donít know anything about computer animation. In other words, to use Oasis youíre going to have to know what a skeleton is used for, what deformers are, what collision detection, particles and dynamics are and all that stuff. That doesnít mean that Iím just going to ignore low end users or thatís is some kind of excuse for making a non-intuitive UI. Itís just that I have to draw the line somewhere. For instance, Iíve already had people ask me if it will support NURBS. The answer is simply no, because I donít like working with them.

By the way, The plan is to release the first version for free and then have a high-end version for money.

Thanks,

-=GB=-

P.S.: I still need some advice concerning the issues I mentioned above.

StefanDidak
01-16-2004, 01:09 AM
Originally posted by ngrava
Maybe latter Iíll add a way to bind in scripting languages.

The other thing is that Oasis is actually going to be aimed at a higher end user.

I don't know what you would characterize as the target high-end user you had in mind... but the concept of binding in (a) scripting language(s) later is something you shouldn't underestimate since it easily affects the entire architecture and foundation of a product.

I've worked on CGI software since the early days where scripting things were 'tucked on' at later stages and I've worked on 3D software where it was part of the architectural design itself. I've also worked extensively on a 3D product that claims to be the #1 in sales which also had its scripting system added in later. Let me tell you upfront... if there is *any* plan at all, even just remotely a rouch hope, wish, or desire to implement any decent scripting you're better off making it part of your design and architecture from the start. Your users will thank you for it and you will have less of a touch time tying up all the ends of a scripting engine that gets tucked on later which will require a whole lot more effort on your part (the kind of effort where the sudden requirement for scripting capabilities can easily lead to something turning into an effort that is disproportional or unfeasible).

If your idea of high-end users is the same as the one I'm thinking of right now then you can't escape the need for having scripting or API extension capabilities. Not taking those into consideration from the inception of the architecture has already proven to be a lot of trouble... for entire teams and each individual within them both on the developer end as well as the user end.

Plan, plan, plan.... ahead, preferably. Plan for things that aren't even part of an initial release. You'll thank me later for it. :)

markyjerky
01-16-2004, 01:22 AM
"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 don't think you need to mess with BSPs to get speed. OpenGL does very nicely with all that's built in for culling.

markyjerky
01-16-2004, 01:39 AM
Rolling your own Event handlers and Widgets ...

Would be a huge waste of time unless you really like that sort of thing.

I've researched just about every cross platform widget kit under the sun over the last 4 years and was paid for some of the research, as it was part of my regular 9-5 at www.on2.com.

In particular I looked at GUI toolkits based on OpenGL like GTK and FLTK. Lots of pitfalls and almost good enoughs. None of the drag and drop designers were any good. I guess if you like scripting GUI layouts with programs ... then there are going to be toolkits for you. I just think all the layout managers for OpenGL programmer are gross.

I wrote a button panel manager for SDL recently and wrote a bitmapfont manager for OpenGL ... but these kinds of things are really not that much fun.

I'd advise against using anything less than using a world class GUI builder of some sort. This would allow you to use the screen mock-up prototyping paradigm at least some of the times.

ngrava
01-16-2004, 04:27 AM
StefanDidak

About scripting in Oasis:

Thanks for you views. I agree with you whole heartedly for the most part. So far, I have a plane to build things in two parts: one is the Core and the other is a set of .dll/.so files that I'm calling the modules. The Core holds all of base classes for GUI, File and memory management, node architecture, animation handlers and scene graph. All the other features are written in dynamically linked modules (plugins, essentially). The modules will consist of things like geometry structures, animation interpolation schemes, IK solvers, skeleton tools and so on. Basically what you might think of as the 'tools'. I'm sure your familiar with the concept. It's far from "new" but it has an excellent feature where, as you develop the base, you are essentially developing the plugin API. This also makes it much easer to add features one by one and thus allows other developers to build onto Oasis by simply sub-classing a node type and filling in the data structures and actions. This way, it allows me to treat everything in the scene graph as a node who's connections can be altered.

Anyway, I'm getting a little off track (sorry). The scripting API thus becomes a simple translation layer to the built in base Oasis classes with some abstraction surgar thrown in to make it easer to digest. sort of like how you can call C++ classes in Python. Also, this allows Oasis to be language neutral.

This is all in theory right now but my experiments have been very encouraging. I'd love to talk to anyone who has worked on and application that works like this... Hint... Hint... :)

Markyjerky,

About BSPs:

Interesting. I think I might just do an oct-tree anyway though. I can foresee a few uses for it in other ways. Maybe Iíll just leave it as an option incase scenes get to big.

About GL and GUI kits:

Yep, all of the tool kits Iíve seen based on OpenGL are pretty gross to me too. ;) Thatís why Iím having to write my own. :P Basically, the mockup of the GUI that I did a few pages back is an exact replica of what I want it to look like. There a four things about it that prevent me from using another GUI tool kit:

1. Transparency across platforms: Almost all the platforms I intend Oasis to run on include some sort of transparency attributes in there api but nothing thatís standard across platforms. And to make things worse none of the app tool kits that I looked at provide for it. Making Transparent widgets in OpenGL will allow me more flexibility and portability.
2. smoothed fonts: again, none of the gui tool kits provide for this. By the way, Iíd love to see the bitmap font manager you wrote. Is it a rasterizer or texture map based?
3. Moving panels: OpenGL can easily animate any aspect of the UI and thatís one of the features Iíve been working on
4. I have a lot of very specific ideas about custom controls and menus that I just canít do any other way then building my own. Doing them on GL will mean that I can make sure that they work exactly the way ďIĒ want them to.

Where things get difficult is trying to build things like standard menus and file dialogs. For that I think Iíll eventually end up coding OS specific panels. That might also keep people from feeling too freaked out about the fact that the UI is so different.

If you look at the UI mock up and think you know of a GUI kit that can make an app that looks ďexactlyĒ like that, then please let me know.

-=GB=-

jashiin
01-16-2004, 08:20 AM
just a few thoughts on the particle-spring idea. it would be really important, for me at least, that what i pose at the current frame, will be exactly in that state if i keyframe the active particle, and later get back to that frame.

this would imply that any real-time dynamics would be out of the question, like secondary motion in the hieararchy depending on how you move around the particle. ( like styling hair in xsi, bad example maybe :) )

the dynamic simulation would have to only include "stable" simulations, only dependent on where the particle is currently at.

itīs a damn difficult question, since i can easily see that youīd want to apply dynamics on a tail for example, and have it swing automatically. but intuitively i feel that any dynamics that happen outside of timeline time (game style dynamics) could get me a pose that would not be recreatable without keyframing the entire hierarchy. to get the exact state of your character or whatever, would require you to simulate from frame 0 to current.

make sense? there is probably a good way of achieving dynamic interaction, getting the best of both worlds. havenīt really tried animanium, but mirai had something like this, albeit it seemed hardcoded for a biped rig (bio-mechanical animation it was called if i remember correctly). cinema 4d & lw 8 seems to have some form of simpler dynamics too, iīd like to know how they handle the posing/frame consistency problem i talked about earlier.

rant rant
jens.
ps. iīve dropped the C toolkit project ;) ds.

iC4
01-16-2004, 02:19 PM
The problem I see when you are using no libraries is, that you have to write all the little details by yourself. No mouse or keyboard input detection (for example glut provides you with mouse motion detection etc.)

iC4
01-16-2004, 02:34 PM
Originally posted by ngrava

2. smoothed fonts: again, none of the gui tool kits provide for this. By the way, Iíd love to see the bitmap font manager you wrote. Is it a rasterizer or texture map based?


maybe this helps:
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=43

Edit:
not sure about your selection problem (don't really understand what you mean with a ortho over a perspective).
but here is very basic opengl selection example.....maybe it helps
http://www.codeproject.com/opengl/openglselectobject.asp

markyjerky
01-16-2004, 06:03 PM
The Bitmap font "manager" is in Manifold.

The only thing it will really show is how very little code it takes to get started. Calling it a "manager" is probably misleading.

It's fairly hard-coded. But it does implement a DrawString that draws a new wide but not very tall bitmap (an image of the string) that coud them be compositied. So it does not speak to compositing the image string.

But it is written in Java ... in a fairly generic fashion. It just renders String(s) Into TARGAs.

ngrava
01-17-2004, 04:52 AM
Jens,

Hey Man! Yep, that all makes sense Hmm... Take a look at this and tell me what you think:

http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml

This is a really fast and simple solution that actually could be made a bit slower and thus more accurate. And, we're not solving for gravity during manipulation. It's actually not really a spring system like I mentioned before but it's based on some of the same principals. I'll have to see how it looks when it's running to really be able to tell for sure, but it looks super simple.

Now that I think about it... I used to work at Hash inc. (makers of Animation:Master) back in 95' and I seem to remember Bob croutcher using springs to make their IK system... I wonder if it's still that way. It would explain situation like - how you can manipulate the elbow separate from the wrist in a chain and it pulls the wrist.

Anyway, That's actually great that you gave up on the tool kit cuz now you can help me out. ;D

iC4-,
About GLUT: I'm afraid I don't really enough about GLUT to know what it has to offer. I just know that it's an OS abstraction layer. I've held off getting too into it because it seems like most people claim it's really old and eventually will loose support. But, I would love it if you can give me some more examples of it's advantages over straight Win32.

About Links: YES! I've need looking for that picking tutorial. I knew I wasn't just imagining it. ;) Thanks a mil IC4- . Did you notice that below that tutorial there is a link to another one that uses raycasting? Man, I'm telling you guys, it's all out there on the net. I've barely had to write any code of my own so far. ;D I'm starting to bad about that...

Oh, and about the ortho over the perspective; all I meant by that was that you draw the scene using GL Perspective and then swtich to orthographic mode and draw the 2D elements right on top of that using alpha blending without clearing the screen. It's kind of clunky but the main advantage to it is that you can use screen coordinates to place your 2D elements. Also you can make them stick to a position that's relative to the size of the window or other elements. That's just what I'm trying to do too. The other way to do it is just to have a bunch of flat plains parented to your camera. That sounds even more clunky to me... There's probably a better way then what I'm doing right now. Does anyone know?

Thanks for all the help guys!! I'm getting closer...

-=GB=-

iC4
01-17-2004, 06:36 PM
iC4-,
About GLUT: I'm afraid I don't really enough about GLUT to know what it has to offer. I just know that it's an OS abstraction layer. I've held off getting too into it because it seems like most people claim it's really old and eventually will loose support. But, I would love it if you can give me some more examples of it's advantages over straight Win32.


well...the only advantage I see is that your app will work for linux too (and if I remember correctly thats what you want)......otherwise the win api has much more to offer and will make your life easier (if you know what you are doing ;) )
And yes glut is really old....there are some others which would do the job fine - since you will make your UI opengl based - you won't need that much.......but just think on the basic stuff....load/save windows......maybe progress bars.....QT would properply do the job.
I think I will go with the win32 api with my application.....than you don't have to care about these problems.


Thanks a mil IC4-
glad I could help :thumbsup:

and the ortho/perspective stuff makes really sense....I think I will try this too - thx!

Hugh
02-03-2004, 07:55 AM
How's it all going? Haven't heard anything for a while....

spinlock
02-03-2004, 03:48 PM
I second Hugh's call for an update: ngrava, how are things going? You've whetted my appetite--I'm really enjoying this thread and I'd love to see it keep moving.

ngrava wrote:
Man, I'm telling you guys, it's all out there on the net. I've barely had to write any code of my own so far. ;D I'm starting to bad about that...

While all these code samples are great, you need to be very careful about the licenses of the code samples if you ever integrate them into your app. Unless accompanied by an explicit license agreement, I believe that the original author retains all the copyrights for the code published. This could pose problems for your code down the line...

Also, regarding GPL: the "code" of the GPL is 'share and share alike' so that if you do copy-paste GPL code from other apps to make yours you are BOUND by the GPL to release your modifications to the code. Again, this could cause you to expose code that you were not planning on (ie: your "Complete" package).

So be very careful what code and ideas you incorporate--I'm not a lawyer, but simply changing variable names in a sample is not enough...

I would have to vote for making this GPL from the get-go:

1) You'll have a cast of thousands and thousands on hand to help with development
2) You'll be able to freely use any-and-all GPL code without fear
3) You can host your project on sourceforge and get all of their goodies for free

Forget about making money selling it--you'll be able to hire yourself out as an Oasis expert. You can do contract work for oodles of money with big firms who want you to write custom plug-ins or may simply pay you to extend features already in Oasis.

Really... for a project like this I think GPL is the way to go. Everyone wins.

Hugh
02-03-2004, 04:04 PM
If you had a core element of the program that didn't use any GPLd code and you didn't want to release the source code to, is it allowable to release your central package as non-GPL and then the functionality of the package as lots of plugins, some of which (if they use GPLd code) are GPL and some of which aren't?

Not sure of the legality of this...

ngrava
02-04-2004, 01:47 AM
Update:

Iíve been a little slow going lately. Iíve been really busy at work with some bids. Thatís all done now so I should have some time to code more this week. Anyway, I wouldnít worry to much about the code Iíve been using from the net. Iíve had to rewrite most of it just to get it to work. I was mostly using it as a way learn more about the particular subject. You know, when youíre starting out, it can be difficult to truly get a clear picture of how things should fit together. Hereís an example: http://www.hinjang.com/gfx/gfx04.html contains some great code for doing subdivision surfaces. However, itís not the speediest code. Nor is it very flexible. But, itís still very good to look over to see how things might be structured. I also found this: http://www.multires.caltech.edu/software/fastsubd/index.html which is some really great code. What Iíve been doing is combining different aspects of these two and some others with some of my own ideas to create my own. Iím not done with it yet and itís probably going to take a little while to get it to the point where itís usable but the whole concept of how subdivision surfaces work is a lot clearer in my head.

Mostly what Iíve been working on is all the mundane stuff (well, what others might consider mundane, I actually love this part). Things like how the buttons are drawn on the screen, keeping them in the same place relative to the window size, making the menus (Man, thatís been a real difficult issue), and figuring out how to do picking and highlighting.

By the way, does anyone who actually has been able to draw anti-aliased text on screen have some insight? What Iím using right now is straight from the NeHe tutorials and itís kind of funky. What Iíd like to do is figure out how to create those 16x16 images of the fonts. So, if thereís anyone who knows, please speak up.

Iíve spent a lot more time with Glut and have decided to use it full time now. Iíve already got the core of the app using all the callbacks I need and itís working like a charm. The main thing that convinced me to use it is that all the examples in the OpenGL Red book are written in it. Once you become familiar with Glut it becomes a lot more clear how to use those examples. Plus, Iíve been able to compile my core in Linux with very little modifications.

Iíve really been enjoying OpenGL programming. Which is great because itís always good to have fun while your programming. ;) There are so many funny little ways of doing things with things like the Stencil buffer, Z buffer and so on. Little tweaky things like moving in and out of view modes and select mode. Itís really fascinating when you do something right and things just work and youíre like, ďWow, it really works?!Ē :D

One last thing, Iím definitely not going to do GPL. This has less to do with making money and more to do with that fact that Iím a really crappie programmer and would really embarrassed to show my code to the general public. If there are people who want to look at it Iíll eventually post it but for now, itís really junky and doesnít have much to offer anyone anyway. If I do include other developers (which I would love once I get the core done) Iíll just host my own CVS somewhere.

Apoclypse
02-04-2004, 11:13 PM
I agree with spinlock though GPl'ing the project is the way to go. Like I said a while back selling an app that uses gpl code in it is bad form, and you would have to guarantee that you software does not use gpl code ( which if you are getting your code from the internet I doubt). Again no one can force you to do anything but I do know that if you use other peoples source in your app you can not release any of the software commercially unless, 1 you have permission from the original author or, 2. you remove all the code ( frankly, this is your first BIG project I don't think you want to write everything from scratch, especially without any help) If you want to write all the source yourself i suggest you start with something smaller until you are sure you can do it without any GPL code in it.

GPL is the way to go if you really want to go ahead with the project now.

iC4
02-04-2004, 11:33 PM
I think he isn't using code from the internet, he just looks on it to get the first ideas on who to get the things done.

if you are reading a nehe tutorial about how to texture a cube and then write your own code there is no copying...

and I think that is what he is doing.

ngrava
02-05-2004, 12:20 AM
Man, so many opinions about GPL. Oh well. Please read my last post and you'll see that I'm not using other people's code (well, maybe a little), just 'looking' at it like iC4- said. I wasn't really serious when I said I hadn't written any code of my own. I was just commenting on the wealth of examples there are out there on the net and how easly that part is. Think of it like this: There are about 6 different ways that I've come across to select objects in the 3d view. All of them are illustrated in great tutorials on the net. After viewing all of them, you pick and choose the bits you like from all of them and make you're own. Actaully, the stuff I really need help with (building a GUI) is not at all documented on the net.

I think just about everyone has chimed in on this so thanks for the insights but enough about that for now please.

What I would love is if people would get more involved in answering some of my actual questions. Don't worry about what may never come. I'm just starting out. GPL is for latter. Spring systems, real-time physics, interpolation schemes and deformations are so much more interesting. Don't you think? huh?

;)

-=GB=-

ngrava
02-05-2004, 12:39 AM
Hey iC4, is that your modeler "eve"? Looks quite interesting!

-=GB=-

M-J
02-05-2004, 10:23 AM
hey ngrava, would you mind posting the links to the tutorials you've found about selecting objects in the 3D view? I need something like that myself right now and I though maybe you could save me some time :)

iC4
02-05-2004, 01:51 PM
there is allready a link in this thread.

and www.gametutorials.com and http://nehe.gamedev.net have also selection tutorials.

@ngrava: yup, thats my modeler, but didn't have much time in the last weeks :(

M-J
02-05-2004, 04:09 PM
thanks alot. hmm, must have missed that link :-(

btw, as I was just reading through this thread in search of this link I came across another thing: some of you were talking about using Python with C++ for GUI issues and other things. But: How do you integrate Python with C++ and vice versa? :blush:

ngrava
02-05-2004, 11:25 PM
Here's those links you asked for:

http://www.dev-gallery.com/programming/opengl/picking/picking.htm
http://frustum.org/3d/
http://www.lighthouse3d.com/opengl/picking/
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=32
http://www.gametutorials.com/Tutorials/opengl/OpenGL_Pg3.htm
http://www.dcc.unicamp.br/~lmarcos/courses/mc603/redbook/chapter13.html
http://www.codeproject.com/opengl/openglmousesellection.asp
http://users.frii.com/martz/oglfaq/selection.htm
http://www.helsinki.fi/~tksuoran/selection.html

Thomas, Nice menus! Care to fill us in? How are you handeling text?

-=GB=-

iC4
02-06-2004, 12:30 AM
oh sorry, but the picture in my avatar is a concept image made in photoshop :)

but I think tomorrow they will look like this picture.

here is an actual shot:
http://www.cgcube.de/eve3d/menus.jpg

the right menus are "marking menus", which only show when you hold down a specific key (or right mouse button). first button is highlighted because the mouse is on it. (print doesn't print the mouse....)

all I have to do now is to put an image on top of the button and I will have the look from the avatar.

at the moment I'm using bitmap fonts with display lists. works pretty good for me.

iC4
02-06-2004, 02:50 PM
ok...so here it is
www.cgcube.de/eve3d/menus2.jpg

if anybody is interested in this, just drop me a line

the marking menu above is created with this:


MMenu markingmenu;

//menu with 6 entries, buttonwidth 70, height 20, hotkey is number 6
markingmenu.initButtons(6, 70, 20, 0x36, hdc, "Arial", 14, 400);

markingmenu.setButton(0,"button1",0);
markingmenu.setButton(1,"button2",1);
markingmenu.setButton(2,"hallo",2);
markingmenu.setButton(3,"test",3);
markingmenu.setButton(4,"sdf",4);
markingmenu.setButton(5,"abcd",5);

markingmenu.checkState(hwnd);

M-J
02-09-2004, 10:03 AM
thanks for the links, ngrava. exactly what I've been looking for :)

M-J
02-09-2004, 10:12 AM
hey iC4-, just checked out your eve3d page, but I'm not sure if I get that whole voxel thing right. I mean, it sounds really cool and I'm excited how it turns out to be, but could you explain this voxel thing to me? What do you mean by 'voxel'? AFAIK voxel stands for 'volumetric pixel' (or something like that :)) but I never heard it being mentioned in a modeling context...

iC4
02-09-2004, 11:09 AM
Jep, a voxel is a volumetric pixel. Let's say you have a simple poly cube. The idea is, that when you convert it into a voxel object it get completly filled with voxels. That means that you will have x*y*z voxels for the cube, depending on your settings. But since I don't need a volume object I will just use a voxel-skin. So there are no voxels inside the cube. Now you have for example 100x100 voxels for each face. With different brushes you can now add or remove voxels and an algorithm calculates this voxel skin back into a poly object.

M-J
02-09-2004, 01:35 PM
ok, think I got most of it... ;) but there are still some questions if you don't mind...

Am I right to assume that this is basically like Maya's Artisan with the exception that Artisan works on vertices? If so, what is the advantage of using voxels over directly manipulating polygon vertices?

iC4
02-09-2004, 01:45 PM
as you allready said you can only manipulate existing vertices, this means you can't add any details (can't add geometry).

the advantage here is, that if you add voxels the algorithm will calculate new polygons, so you are adding real geometry and you are not only re-positioning the vertices. With artisan you are limited to your face count, so you can't add for example veins if your model isn't subdivided high enough. With the voxels I can set a value which says how detailed the end mesh will be. The algorithm will calculate faces from the voxels, and depending on a value it will skip "single voxels".....hm...hard to explain in english :)

M-J
02-09-2004, 03:06 PM
:) ja, ja... mit dem Englisch hab ich auch immer so meine Probleme... aber ich glaub ich hab's so ziemlich kapiert. Ich werd noch mal drŁber nachdenken und falls es Dir nix ausmacht einfach fragen, weil die Idee hŲrt sich echt gut an. Bin gespannt was dabei rauskommt... ;)

ciao, Martin

hohehohe2
02-10-2004, 03:34 AM
Hi, I heard voxel modeling is used to
design complicated free-form object such as cell phone.

ngrava,
Thanks for the link to Hitman: Codename 47's simulation engine algorithm. It's quite interesting.
Just one thing. If you are making oasis for money, beware of patents.
For example Alias has parents for dependency graph.

playmesumch00ns
02-10-2004, 09:09 AM
And marking menus are their IP too iirc.

iC4
02-10-2004, 02:48 PM
hmm...but when is a menu a marking menu and when is it just an extented pop up menu?

does this mean that you are allowed to create a pop up menu, but you aren't allowed to use "zones" in this pop up menu? or aren't you allowed to display a pop up menu with a key pressed instead of the right mouse button? :)

StefanDidak
02-10-2004, 03:03 PM
Originally posted by iC4-
hmm...but when is a menu a marking menu and when is it just an extented pop up menu?


In legal terms a marking menu is only a marking menu if it fits the specific criteria of the patent. If it doesn't fit... it's a popup menu or something 'new'.

does this mean that you are allowed to create a pop up menu, but you aren't allowed to use "zones" in this pop up menu? or aren't you allowed to display a pop up menu with a key pressed instead of the right mouse button? :)

It's been a long time since I read through the actual patent description itself but I recall it was very specific towards only a few of the features which included the way the line of direction would intersect with a function on the markingmenu, it's layout style and appearance, and its drag-intersect-release mechanism. Other than that it's really just another popup menu. :)

Some patents are worth the effort, other just seem frivolous. Like, for example, the tabbed containers of Adobe with its tab-attach and window-detach functions.

jashiin
02-11-2004, 01:01 PM
i wonder how strong the patent on the alias dependency graph is...
http://www.alias.com/eng/about/research/patents/file/US05929864.pdf
considering how abstract it is, you could easily pick out quite a few applications that could be violating this.
it's picky to the extreme about what defines a dependency graph, but still, depending on how you look on it, it's a damn wide patent as well, since connections between software components with specified attributes is something people... tend.. to... use? ;)

what they're really wanting to protect, data dependecy graphs, hasn't it been done for a loooong time in houdini, digital fusion and others? if it has, would it hold up in court?

jens.

StefanDidak
02-11-2004, 01:12 PM
Originally posted by jashiin

what they're really wanting to protect, data dependecy graphs, hasn't it been done for a loooong time in houdini, digital fusion and others? if it has, would it hold up in court?


I haven't looked at the details of the patent but in general a patent means absolutely nothing and is worth nothing if you are not ready to defend it in court. Having patents but not having the strength and determination to enforce it means you have patents that are financially worthless.

If, in court, you can prove that others have infringed on the patent as well (assuming here that the broad scope of the patent does indeed cover many other implementations in other products) and that the holder of the patent knew about it and didn't enforce the patent then the patent would not hold up in court. Having patents means having the responsibility to defend them. Not doing so will ultimately render patents that are infringed on useless (at least as far as legal remedies go).

ngrava
02-11-2004, 06:32 PM
Originally posted by hohehohe2
Hi, I heard voxel modeling is used to
design complicated free-form object such as cell phone.

ngrava,
Thanks for the link to Hitman: Codename 47's simulation engine algorithm. It's quite interesting.
Just one thing. If you are making oasis for money, beware of patents.
For example Alias has parents for dependency graph.

I'm not too worried about that. You can't really patent a dependency graph since it's been used in hundreds of applications all over the world since the 60's. The patent has more to do with the specifics of how it's used.

By the way, Gamasutra has a great article about dependency graphs here: http://www.gamasutra.com/features/20030829/vanderbeek_01.shtml

Thanks for the advice though.

-=GB=-

ngrava
02-26-2004, 06:47 AM
I got a mail the other day but was not able to reply due to some silly limit so I'm just doing it here in the hopes that Eliot sees it.


emack wrote on 01-16-2004 07:05 PM:
You might want to email Ton Roosendal about the upcoming Blender 3.0 project . . . there is probably a lot of overlap and you might find lots in common as well as people to help. Here's the link about their 2004 plans.

Eliot

http://www.blender.org/modules.php?op=modload&name=News&file=article&sid=105&mode=thread&order=0&thold=0


Hey! Sorry about not getting back to you in a timely manner. I just discovered the cgtalk mail. :) Thanks for that link. I'll do some research.

From looking at past versions of Blender I have to say, that's exactly why I want to make a 3D program. If you ask me (and I realize that this is just 'my opinion' and that most people who use it are happy with it) Blender has many great features... Excellent features even, trapped under one of the worst interfaces I'm had the misfortune of using (sorry). Just simple navigation can be painful for me. So, this is exactly why I want to make Oasis. To me, the interface of human and computer needs some polishing up and much more thought put into how people or animators in this case, interact with digital characters.

To me, all of the great technologies for 3D animation have just about been created. But they just need to be combined in the right way. Thus Oasis will be a merging of technologies that would otherwise exists in separate places. For example, I have an idea that I've been working on called the "Physical Animation Environment". It's really quite simple, as an animator drags objects around on the set, they'll calculate for collision detection in real-time (or as close to it as possible). When something collides, it can either push that thing around or be stopped dead. Feet wonít dip into the floor because Oasis sees this as an actual physical object. Characters canít put theyíre hands through theyíre faces and so on. The math behind this is simple game physics. Very well documented and many of the problems already worked out. The Skeletal system is based on a "Interconnected Masses" system which is very similar to a spring system in that it uses particles with mass and velocity and so on. They will pull each other around very easily. This makes a very cool dynamic IK-like system that doesn't have the overhead of angle calculation. Just vectors. Plus, you can grab and pull from either end of the chain. It's really cool and lots of fun. Again, this is simple math but has yet to be used like this. At least as far as Iíve seen. ;)

Now, there's nothing new about computer simulation at all. In fact, what I'm currently using is quite rudimentary. But, it's never been used in quite the same way as this. So, it's going to be more about the interface and ease of use then the actual hard core algorithms. I know that seems contrary to how most programmers think but I feel it's a fresh look at the issues that currently exists.

Thanks again,

-=GB=-

Tripdragon
02-27-2004, 12:52 AM
all of it sounds great, just keep us up to date and post some movs and screenshots when you can :D ^v^

Hugh
06-22-2004, 10:52 PM
I was just wondering how all of this was going - have you made any progress on it?

Would love to get an update...

operativem
06-23-2004, 04:20 AM
if i were you, i'd license proven, open-source implementations for your scene graph, rendering, interface, etc. i wouldn't waste time trying to re-invent the wheel. i have a lot of experience doing this sort of thing and it's nearly always better than trying to design something that's outside your specialty. for example try openscenegraph.org for your scene graph. (i am not associated with them in any way.)

ngrava
05-06-2005, 05:58 PM
Hi Folks,

Just a little update. Oasis has been sitting on the back burner for about a year now but I haven't given up on it at all. In fact, recently I've been looking at some interesting developments with Python. Have any of you seen Psycho? I've been running little tests and it seems to work really well. If all works out I could be picking up Oasis Development pretty soon.

About Open scene graph: Yes! This is an excellent suggestion and exactly the direction I've been headed. Actually, what you're suggesting is exactly the reason I decided the start working on Oasis. It's funny because I find that the hardest thing is downloading all the different options and testing them out. I have a lot of junk on my hard drive now. ;)

-=GB=-

Hugh
05-06-2005, 06:00 PM
Woah! I'd forgotten all about this!

Glad to hear it's still moving - looking forward to more updates...

dotTom
05-07-2005, 03:31 PM
If you're going to embark on a large dev project then regardless of what it is I would recommend you use some kind of source code control system (SCCS). If you're using Visual Studio then you could use Visual Source Safe if you're really desperate. My first choice would be Perforce. You can actually download a feature complete, two user licence, version of Perforce for free. Perforce is by far the best SCCS system I've used.Just my 2p / 2c (delete as applicable) worth.

ngrava
05-08-2005, 08:51 AM
Yeah, I've looked into this before. I use Komodo for my Python stuff and it supports CVS, Perforce and Subversion. I have to confess that I've never used any kind of source control before so I don't have any idea how to go about setting that up at the moment. I'll probably get to that a bit latter when I actually have some stuff that needs tracking in that capacity. Thanks for the tip though. :)

-=GB=-

dotTom
05-08-2005, 09:26 AM
Using an SCCS is not just for volume, I use it on relatively small bits of code (circa a few 100 to a few 1000 lines), it just lets you "roll back" bad engineering decisions and also lets you annotate the reasons for your changes. So even in a single user environment its a good idea. Heck, I throw my Maya models into my local Perforce DB (saves having all those Foo00027.mb on disk). Wouldn't it be ace if Avid did a reasonably priced 1 or 2 user max version of Alienbrain.

No disrespect to your project, but what I'd love to see rather than another modeller is a decent Open Source SCCS/asset management system aimed at the DCC market specifically. There's a lot of creative development talent out there and speaking personally I kind of feel that between Maya, ZBrush and Modo modelling is fast approaching the status of "solved problem" (unless or until someone implements the mythical "artistic talent" button). There are other parts of the creation pipeline that could do with some serious lovin' up in terms of attention from the dev community.

ngrava
05-08-2005, 10:13 AM
Yep, I'll have to look further into SCCS. I'm sure there will come a time very soon that I'll need to use it. Right now, I'm still experimenting and planing. But your point is well taken about the versioning aspects of it. I can definitely see that becoming very useful.

I should mention that this project isn't actually a modeler. In fact, that's exactly what it won't be for. There are a number of really great free or very cheap modeling and rendering tools out there but nothing really for animation. I'm not talking about just moving one object from point a to point b. I'm talking about a complete and extensible architecture for character animation from rigging on down to point level animation.

Two things got me onto this: 1.) A total lack of good, free, 3d animation tools under Linux and 2.) the availability of relatively fast, pre-made librarys for doing a lot of this in the form of game API's and scene graphs. Basically, I've been seeing a lot of free game API's become more and more sophisticated over the years. To a point where I'm seeing an overlap into Highend 3D graphics use. Using Game libs and other readily available tools, programmers can implement things like real-time physics, mesh deformation, skeletal motion, IK, etc., etc. into a real-time animation environment without having to write that code themselves. This is basically what I'm up to. If you look back to the first few pages, you can read more about it.

It's a pretty huge task at the moment but I have some ideas about how to make it so insanely cool that someone just needs to do it.

-=GB=-

buttachunk
05-14-2005, 03:08 AM
GB,

excellent work so far-- I just read every post.

I love the UI still-- it looks fantastic.

I agree that there is a real need for a great free 3d animation program under Linux, and I believe the same is true for compositing and editing. Once you have Oasis to the .9 stages, it may be interesting to take your UI core and adapt it to an editor and compositor. Perhaps include the same particle system from Oasis into the 3d compositing module, possibly integrate Cinepaint as a paint module (modified for 3d), and add an editing module (timeline and tools plus access to compositing effects). The whole app could run in OpenGL. Many of the processors are built-out already as source-code at sourceforge, like the motion-tracker and such.

ngrava
05-15-2005, 10:37 AM
Hey cool! Thanks! I hadn't thought about video editing. That's a funny one though. Lot's of device control crap that I know nothing about. Not to mention all the fireWire communication stuff... I'll let someone else write that. :D Ok, It's actually really great that you bring this up because this is just the sort of thing I need to be thinking about. The core needs to be able not only be open but very forward thinking in design. It's kind of mind boggling when you think about it. The core at this point, is the most important part of the whole program. It needs to be Sub-modular or modular within modular. :) I need to make it flexible enough to extend in ways I can't even imagine... Ugh!

I've been thinking about the interface lately. Particularly the graph editor. The more I animate at work, the more I'm beginning to think that the Pixar way of having a huge muti-track curve editor is not such a bad idea. And, that the way I had envisioned it as a little pop up view/window above the time line isn't going to cut it.

But now I have a problem, If I make the graph editor larger, then there goes your screen realestate. The way they do it at Pixar is to have most of the screen showing the this huge window with little floating windows for the 3D views. This is actually counter to one of the main things that makes Oasis special in my mind. Keep the buttons and numbers out of peoples faces and just bring them in when you need them but never totally obscuring the main window... Does that make sense? So, how I'm going to solve this is a real challenge if I may say so. The problem would be null if we all had dual monitors though. ;)

-=GB=-

buttachunk
05-16-2005, 04:14 AM
The core needs to be able not only be open but very forward thinking in design. It's kind of mind boggling when you think about it. The core at this point, is the most important part of the whole program. It needs to be Sub-modular or modular within modular. :)

yes, it seems kindof analogous to painting; the core is the palette and the processing modules are the paint.


I'm beginning to think that the Pixar way of having a huge muti-track curve editor is not such a bad idea. And, that the way I had envisioned it as a little pop up view/window above the time line isn't going to cut it.


You don't have to start by reinventing the wheel-- it's a process.

I actually love the curve editor in the UI shot-- very streamlined and efficient. To me, it really shows that Oasis is designed to assist an artist to make animations rather than to work on an animation program. Hope I'm saying that correctly.

My advice would be to start with the one you have and see what reaction you get from other artists. Then perhaps add another window as an option later. I think you have an excellent concept for the UI and flow of the app, and would be very interested in beta testing for you.

buttachunk
05-16-2005, 04:15 AM
double post:eek:

ngrava
05-22-2005, 10:25 AM
yes, it seems kindof analogous to painting; the core is the palette and the processing modules are the paint.



You don't have to start by reinventing the wheel-- it's a process.

Yep this is true. Unfortunately or fortunately, I plane on doing a lot of reinventing of the wheel. Along with a healthy dose of not reinventing the wheel... Uhh did that make any sense? I guess what I'm trying to say is that I really want to challenge a lot of the ideas that people have about CG animation. There are things that are done in 3D programing that people don't even question. Is that really the best way to do it?

Take the notion of hierarchys for example. While it's true that they exist in the real world, they don't always work for what we need them to do. When your foot touches the ground, it suddenly becomes a potential point of rotation for the whole body. whenever an object touches another object, that point of contact becomes a center of rotation. This totally destroys the concept of hierarchys. Is there some other way of defining connections between entities thats less constrictive? something maybe, bi-directional or force based? I don't know just yet but you can bet that I've been racking my brain over it.

Here's another one that I'm very interested in: Vector based rotations = no gimble.

And another: a lot of people have issues with seeing separate X,Y, Z channels in a graph editor and understanding how they translate into 3D space. Why not just let them manipulate the curve in 3D space? What about rotations? Well, since we would be dealing with vectors, you now have a 3D path you can see and manipulate as well.

Vector rotations aren't exactly earth shattering but it's a start that opens up a whole new path of options.

I don't want to fix what's not broken. If the way it's done now is working then why change it. But, There's a lot of stuff that I've been thinking about lately that I do think is broken or at least needs to be further looked into. All of those things point to the main reason why I feel I have to make Oasis. It's not that I want to make a program that's almost or just as good as Maya, XSI, Max, etc., etc. Oasis has to be something special. Otherwise, why do it? Right? ;)

I actually love the curve editor in the UI shot-- very streamlined and efficient. To me, it really shows that Oasis is designed to assist an artist to make animations rather than to work on an animation program. Hope I'm saying that correctly.

Thanks so much for the positive feedback. :) And yes, that's totally my aim. I'm really glad you like it.

My advice would be to start with the one you have and see what reaction you get from other artists. Then perhaps add another window as an option later. I think you have an excellent concept for the UI and flow of the app, and would be very interested in beta testing for you.

Excellent! Again, thanks for the feedback. I think you are right. I'll keep it the way it is for now.

visualboo
12-24-2005, 06:18 AM
Galen, any update?

HelmOfFire
09-18-2006, 10:18 PM
could not resist to bump it up - really interesting what's going on with this project

ngrava
09-18-2006, 11:23 PM
Galen, any update?


Yep, still working on the core in my spare time. I'm also working a regular job so it goes a little slower then most projects. One thing I'm working on is getting Cairo (http://cairographics.org/) to render on top of OpenGL. I thought it was possible but maybe not. Writing the user interface is basically where I'm at. There are so many different ways I could do it and since I'm not that great of a coder, it's even more difficult for me. :) My main issue is just drawing windows inside a GL or GLUT window. No so much of a big deal but when you consider that I want to use Antialiased fonts and transparent panels I'm finding that I have to write a whole interface based on OGL. So, I've been looking at different vector graphics and GL libs to see if I can use a ready made one that works better. believe it or not, I've had the best results so far with SDL and Pygame. :) I'm also looking at OSX to use as my main development platform. Windows is just going to sh*t in my opinion so I got a Mac and I'm loving it to death. Oasis will still be cross platform though.... maybe.... ;)

-=GB=-

DSedov
09-19-2006, 11:07 AM
What exactly are you using SDL for?
What are you using as your event handler?
What are the roles of GLUT and SDL in your programm?

Really interesting stuff you're doing. Im building a program my self (its more of a multy platform on-line 2K editor, and I was wondering what libs do you use for what. There are so many choices that it is confusing

ngrava
09-19-2006, 06:23 PM
SDL provides just about everything for you in a very simple and easy to use package. It can be a little to simple though. for main loop stuff, you just need to make a while statement that says, "While not 0, do the contents of this loop". Then inside the loop you have all your checks, callbacks, frame advances and screen redraws. Those are usually the API specific stuff and SDL provides just about all of that. But SDL isn't the only way to go. It's just nice because it so simple and provides handing of images, OGL, sound, mouse and keyboard. I think it was intended for games but it's really useful as simple starter platform. Anyway, I'm starting to sound as if I'm trying to sell SDL. But it's quite the opposite. I actually ran into some issues that made it really hard to continue (Mostly to do with Open GL and SDL) so I've been looking at other libraries too. Unfortunately, there isn't anything else as simple as SDL that I've been able to find.

GLUT is where I started and I continually go back to it now and then and try to force it to do things it wasn't meant to do. It's very basic. OpenGL, mouse, keyboard, menus and a simple right click menu. That's it. But again, as a starter package, it does it's job. The nice thing about GLUT and SDL is that they are totally cross platform. That's something that's really important to me. One of the early notions that I had about Oasis is that there just isn't any kind of good 3D animation program for Linux (other then Blender). So whatever I make has to be able to run on Linux and OSX.

DSedov
09-20-2006, 08:30 PM
Hello!

What limitations of GLUT have you run in to? Also how SDL is better over GLUT and what problems did you run into using SDL with OpenGL?

SDL provides just about everything for you in a very simple and easy to use package. It can be a little to simple though. for main loop stuff, you just need to make a while statement that says, "While not 0, do the contents of this loop". Then inside the loop you have all your checks, callbacks, frame advances and screen redraws. Those are usually the API specific stuff and SDL provides just about all of that. But SDL isn't the only way to go. It's just nice because it so simple and provides handing of images, OGL, sound, mouse and keyboard. I think it was intended for games but it's really useful as simple starter platform. Anyway, I'm starting to sound as if I'm trying to sell SDL. But it's quite the opposite. I actually ran into some issues that made it really hard to continue (Mostly to do with Open GL and SDL) so I've been looking at other libraries too. Unfortunately, there isn't anything else as simple as SDL that I've been able to find.

GLUT is where I started and I continually go back to it now and then and try to force it to do things it wasn't meant to do. It's very basic. OpenGL, mouse, keyboard, menus and a simple right click menu. That's it. But again, as a starter package, it does it's job. The nice thing about GLUT and SDL is that they are totally cross platform. That's something that's really important to me. One of the early notions that I had about Oasis is that there just isn't any kind of good 3D animation program for Linux (other then Blender). So whatever I make has to be able to run on Linux and OSX.

DSedov
09-20-2006, 08:38 PM
Ohh.. also, what graphics programming comunity are you also visiting. I doubt there are any forums for programming DCC kind of stuff (like Maya, Shake etc). But there must be something on-line to help getting started.

Also my interest is more in creating programs to work with 2K log imagery then 3D, but that staff is also hard, and relies on fast OpenGL even more. (look at hardware requirements for programs like Nucoda, Scratch, Baselight, iQ - they all require you to use Quadro FX 4500)

rendermaniac
09-20-2006, 08:50 PM
You may also want to look at WxWidgets http://www.wxwidgets.org/ and Qt http://www.trolltech.com/products/qt which are cross platform and have a lot more widgets.

However if you want to do anything really fancy beyond what a toolkit provides - like transparency etc then you will have to build it yourself from OpenGL, and all the control handles etc. It's a lot of work!

Simon

playmesumch00ns
09-21-2006, 09:58 AM
I'd second simon's suggestion. Have you looked at python and PyQt? python and Qt are fast becoming de-facto standards in the industry.

I'd strongly suggest doing the main UI and logic code in python, and binding your c++ data types and complex operations to it, probably using boost::python.

ngrava
09-21-2006, 10:22 PM
Actually, Simon also pointed out the reason that I'm not going to use a UI kit. ;) If you look at the Oasis mock up image on page... ahhh... 2 I think? anyway, that image is how I want it to look "exactly". There is no interface kit for that. I have to build it all on my own. It's really not that difficult once you have a few primitives built, you can use them all over the place. That's what I've been doing mostly. Figuring out how to make panels slide out form the sides of windows and having them snap into place when they get close to each other. I had a version that just used OpenGL inside GLUT that worked. What I did was to draw the 3D data first using a perspective matrix then switch to GLUT_Ortho veiw (or something like that I can remember right now) and draw the 2D interface. however, if you want to use the GL selection buffer, your screwed. The selection buffer doesn't handle what happens when you want to grab a handle that is covered by a panel. So, in that case, you have to build some kind of ray casting selection engine that looks at everything under the mouse. I think there my be a way to make it so that you have two buffers. One for the interface and one for the 3D. Anyway, enough about that. I'm really not sure anyway about all that. I've never gotten a selection buffer to work just yet. :)

seadonghai
10-04-2006, 05:51 AM
Hi , I think your project is great ,but Could I give you some advice?

1,UI is not the core of 3d software ,structure is the important.

2,what is your 3d software's strong suit.Dynamic ? crowd animation ?... ...

I like simulate crowd animation by fuzzy logic and skelecton animation .I colud help you if you like.

thank you

CGTalk Moderation
10-04-2006, 05:51 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.