Cheetah3D 4.0
- Thread starter Modeler
- Start date
My Christmas wish list for the next version of Cheetah:
1. Bevel and chamfer tools- both on edges and points
2. Join polygons (select any number with adjacent edges and make them into one- eliminate the unnecessary)
3. Save material files and export/import them (in sets/folders)
4. More scripts- the best scripts installed by default
5. Area select as default? Lasso/rectangle/oval option
Keep up the great work!
1. Bevel and chamfer tools- both on edges and points
2. Join polygons (select any number with adjacent edges and make them into one- eliminate the unnecessary)
3. Save material files and export/import them (in sets/folders)
4. More scripts- the best scripts installed by default
5. Area select as default? Lasso/rectangle/oval option
Keep up the great work!
Martin
0
Martin
0
3.5 wishes of your list have a very good chance to be implemented within the next six months.:wink:
Bye,
Martin
I'm curious as to which 1.5 features are going to be missed out.
1 -- fairly easy.
2 -- almost trivial (heck, fill hole is essentially that tool)
3 -- save material files -- surely very easy
4 -- more scripts / best scripts installed by default -- surely very easy
5 -- area select as default -- again, surely easy as a preference item (not sure I want this, so I could live with it as 1.0 of the 1.5 ;-) )
1 -- fairly easy.
2 -- almost trivial (heck, fill hole is essentially that tool)
3 -- save material files -- surely very easy
4 -- more scripts / best scripts installed by default -- surely very easy
5 -- area select as default -- again, surely easy as a preference item (not sure I want this, so I could live with it as 1.0 of the 1.5 ;-) )
Martin
0
1. I'm happy to hear that you still consider a chamfer tool as an fairly easy to implement tool. Because I plan to release a Plug-In SDK which allows to write such tools. And since it is fairly easy for you I would be very happy if you could write one.:wink: See the screenshot with the edge selection below to understand why I think it belongs to the more difficult tools. And this example wouldn't consider self intersections at all. I have much more complicated examples in mind. I expect that a good chamfer tool has at least 2000 lines of code. Probably more.
2. Please look at the second screenshot. Do you really believe the fill hole tool can handle that case.
I don't think so. I first have to support N-Gons with holes which require a rewrite of all polygon tools. Is that trival? NO. That means updating ten thousands of lines of code. But that is one of the things I plan to do.As you can see for trivial cases like merging two quads or chamfering the cover of a cylinder these tools are indeed trivial. The general cases aren't. But you have to consider all cases to write a good tool. Not just the trivial ones.
Bye,
Martin
Attachments
First, let me apologise for my use of the word "trivial". I was trained by mathematicians, so to me it means "a series of pretty obvious steps, but obviously doable" versus "something you could do with no effort".
... but:
First: I actually don't want a "merge polygon" tool so much as a "delete edge and merge adjacent polygons" tool -- which I think is pretty simple to implement, no? In fact it's what I think most people expect when they delete an edge. It's even easy to refuse to do so if the adjacent polygon normals aren't sufficiently similar, no?
Second, given that you implement the preceding, it can be used to implement "merge polygons" via fairly trivial recursion:
1) Convert selection to edges
2) Apply "delete edge and merge adjacent polygons" to every edge in the selection which is has two other incoming edges in the selection.
Third: Note that the "delete edge and merge adjacent polygons" tool would presumably refuse to work if the polygon on both sides of an edge is the same polygon, so you wouldn't necessarily run into this problem with the solution I'm proposing.
Fourth: OK, it will still annoy folks wanting to create walls with windows in them, so that's an issue.
It seems to me that if you can't implement polygons with internal holes by subclassing, your codebase has problems.
The hard part will be implementing stuff like starting a scalpel cut in the middle of a face. Handling a polygon with interior holes as a set of convex polygons for rendering purposes is fairly straightforward.
Scripting Wishlist
I'd love to work with either a plugin SDK or the scripting system, but it's pretty annoying to program in an environment with no starting point documentation, no debugger, no command line, or even the ability to dynamically load scripts without restarting. I'm blown away by what some of the scripters have done (especially you-know-who ) but it seems a little too much like hard work to me ;-)
The bevel tool is essentially your inner extrude tool with mechanical post-processing (described in an earlier post). It's easy to make it work just as generally as inner extrude does (yes, it will have problems with pathological cases -- so does bevel). Chamfer -- which I don't care much about -- is an interpolated bevel.
OK, fill hole won't work for nutty examplesPlease look at the second screenshot. Do you really believe the fill hole tool can handle that case.
... but:First: I actually don't want a "merge polygon" tool so much as a "delete edge and merge adjacent polygons" tool -- which I think is pretty simple to implement, no? In fact it's what I think most people expect when they delete an edge. It's even easy to refuse to do so if the adjacent polygon normals aren't sufficiently similar, no?
Second, given that you implement the preceding, it can be used to implement "merge polygons" via fairly trivial recursion:
1) Convert selection to edges
2) Apply "delete edge and merge adjacent polygons" to every edge in the selection which is has two other incoming edges in the selection.
Third: Note that the "delete edge and merge adjacent polygons" tool would presumably refuse to work if the polygon on both sides of an edge is the same polygon, so you wouldn't necessarily run into this problem with the solution I'm proposing.
Fourth: OK, it will still annoy folks wanting to create walls with windows in them, so that's an issue.
It seems to me that if you can't implement polygons with internal holes by subclassing, your codebase has problems.
The hard part will be implementing stuff like starting a scalpel cut in the middle of a face. Handling a polygon with interior holes as a set of convex polygons for rendering purposes is fairly straightforward.
Scripting Wishlist
I'd love to work with either a plugin SDK or the scripting system, but it's pretty annoying to program in an environment with no starting point documentation, no debugger, no command line, or even the ability to dynamically load scripts without restarting. I'm blown away by what some of the scripters have done (especially you-know-who
) but it seems a little too much like hard work to me ;-)Attachments
Last edited:
Wow, that's quite immense.
At least if you just read that a Ray-Tracing 3D Renderer like this (see link) was coded in less than 2 days and with just 800 lines of code:
http://www.superjer.com/pixelmachine/?
…but who am I to judge about about this.
Martin
0
Hi,
the reason why it only took 800 lines is that it only supports boxes and spheres which are very easy to intersect. Such a renderer can be easily written in two days.
The renderer in Cheetah3D takes approx. 5% of the source code. So the renderer is just a very small part of Cheetah3D.
The inner extrude tool currently has 700 lines of code. Transforming it to an bevel tool might add another 300 lines. But a bevel is just a trivial case of a chamfer. So a good general chamfer tool is therefore considerably more complex. I guess it might take another 500 to 1000 lines which brings us to the estimated 2000 lines.
And please don't forget that the polygon tools are interactive, have a UI, can be undon, work in point/edge and polygon mode etc. This stuff also adds some work to the tool itself.
After writing ten thousands of lines of polygon tools code I'm quite sure that I can estimate such things quite well.
If you have unlimited time writing such a tool is indeed easy. If the time is limited and you are working on two other big features it becomes difficult to add such a tool in-between. Even if podperson says it is easy and makes a nice drawing.:wink: It is also easy to run 100m in 20sec. The problem is when you want to run it in under 10 sec.
Bye,
Martin
the reason why it only took 800 lines is that it only supports boxes and spheres which are very easy to intersect. Such a renderer can be easily written in two days.
The renderer in Cheetah3D takes approx. 5% of the source code. So the renderer is just a very small part of Cheetah3D.
The inner extrude tool currently has 700 lines of code. Transforming it to an bevel tool might add another 300 lines. But a bevel is just a trivial case of a chamfer. So a good general chamfer tool is therefore considerably more complex. I guess it might take another 500 to 1000 lines which brings us to the estimated 2000 lines.
And please don't forget that the polygon tools are interactive, have a UI, can be undon, work in point/edge and polygon mode etc. This stuff also adds some work to the tool itself.
After writing ten thousands of lines of polygon tools code I'm quite sure that I can estimate such things quite well.
If you have unlimited time writing such a tool is indeed easy. If the time is limited and you are working on two other big features it becomes difficult to add such a tool in-between. Even if podperson says it is easy and makes a nice drawing.:wink: It is also easy to run 100m in 20sec. The problem is when you want to run it in under 10 sec.
Bye,
Martin
Martin
0
Sorry but that would only work in C++ text book dream land. In reality all the tool still won't know how to handle holes. Because for extrude, move, subdivide, etc. holes have a completely different meaning. Therefore these tools have to learn how to handle holes correctly. And that requires more or less updating most polygon tools, file loaders, drawing, etc..
But it would be really nice if things would be that easy.:wink: Unluckily even with the best OO code that won't work.
So I have to do it the hard way.
Bye,
Martin
Last edited:
Well, that explains a lot
Sure. And my post was not meant to criticise you.
As a hobby programmer who never coded anything related to 3D in his life it just made me wonder.
You do great work! And the fact that C3D is the work of one man is even more impressive. :icon_thumbup:
That's not really true. If you wrote your code base with the assumption that polygons would always be convex that allows you to take a lot of things for granted in other parts of the code. Most game engines and tools make this assumption, and for good reasons.
Once concave polygons enter the picture things get MUCH more complicated.
Well ... you know your code better than I do, obviously.
It seems to me that some kind of abstraction layer is already present in your existing code since you store polygons independently of the rendered representation (triangles).
I do realize that interactions with existing tools will be hairy, since one obvious implementation of a subclass would not allow the inner polygon edges to be edited.
Assuming that there is a "face" or "polygon" class, creating a "hole" subclass that has two new members: parent and next_hole, and adding a first_hole member to the existing polygon class ... and then adding new code to tesselate faces with holes ... would pretty much get you there. The holes and the containing faces can still be edited normally. Extruding a hole works EXACTLY as extruding a face does now (assuming that you insert geometry "below" the extrude). Obviously, a face with holes is prone to be pathological if not roughly coplanar (including holes) ... but it's not like that problem doesn't exist for ordinary faces.
Edit: of course you could just add "parent" and "next_hole" and "first_hole" to the base polygon class for the same result. (It then follows that a hole can have islands inside it...) I've not see a modeler that supports this
I think you said something about having licensed code for better booleans which, among other things, is predicated on having support for all of this functionality.
Concave polygons are rendered as collections of convex polygons. Detecting how to split up the underlying n-gon is *fairly* simple actually -- assuming that it's possible -- if it isn't, you're always going to get bad results.
And, again, everything is, at heart, triangles. Figuring out how to break up an ngon into triangles is at the heart of everything. Cheetah 3d is already dealing with this issue (you don't need holes to encounter the problem).
The attached image shows the same object distorted in two different ways and C3D automagically tesselating the top face correctly in each case. (As you move around the top vertices, the underlying tesselation adapts itself.) This means that the polygon representation is dynamically (and correctly) being converted into triangles for both the edit view and the renderer.
I do realize that interactions with existing tools will be hairy, since one obvious implementation of a subclass would not allow the inner polygon edges to be edited.
Assuming that there is a "face" or "polygon" class, creating a "hole" subclass that has two new members: parent and next_hole, and adding a first_hole member to the existing polygon class ... and then adding new code to tesselate faces with holes ... would pretty much get you there. The holes and the containing faces can still be edited normally. Extruding a hole works EXACTLY as extruding a face does now (assuming that you insert geometry "below" the extrude). Obviously, a face with holes is prone to be pathological if not roughly coplanar (including holes) ... but it's not like that problem doesn't exist for ordinary faces.
Edit: of course you could just add "parent" and "next_hole" and "first_hole" to the base polygon class for the same result. (It then follows that a hole can have islands inside it...) I've not see a modeler that supports this
I think you said something about having licensed code for better booleans which, among other things, is predicated on having support for all of this functionality.
Background Note: I have written a realtime 3d renderer from scratch. I've also written a 3d animation tool from scratch (very primitive compared to C3D ... but then it was 1991).
Concave polygons are rendered as collections of convex polygons. Detecting how to split up the underlying n-gon is *fairly* simple actually -- assuming that it's possible -- if it isn't, you're always going to get bad results.
And, again, everything is, at heart, triangles. Figuring out how to break up an ngon into triangles is at the heart of everything. Cheetah 3d is already dealing with this issue (you don't need holes to encounter the problem).
The attached image shows the same object distorted in two different ways and C3D automagically tesselating the top face correctly in each case. (As you move around the top vertices, the underlying tesselation adapts itself.) This means that the polygon representation is dynamically (and correctly) being converted into triangles for both the edit view and the renderer.
Attachments
Last edited:
Martin
0
Hi,
today N-Gons are normally triangulated. That has various advantages. OpenGL loves triangles, you can easily intersect them and you can easily export the data to file formats which don't support N-Gons.
Triangulating normal nicely shaped concave N-Gons without holes is quite easy. Triangulating complex N-Gons with holes, self-intersectiosn, etc. is one of the most difficult problems in computer graphics at all. And with difficult I mean it takes years to write a really good triangulator. After trying to make my own stable for many months I finally licensed FIST, which is probably the best triangulator you can buy. Its under development since almost 10 years and has an amazing 25k lines of code. 25k lines just for triangulating polygons. I think that says everything about how complicated it is to make triangulation robust.
Booleans are quite comparable in complexity. They look simple but they can cause tons of headaches. As triangulation they are also very prone to numerical problems.
Luckily there exist middle ware companies today which sell these high end algorithms.:wink: Even although they are not cheap.
Bye,
Martin
today N-Gons are normally triangulated. That has various advantages. OpenGL loves triangles, you can easily intersect them and you can easily export the data to file formats which don't support N-Gons.
Triangulating normal nicely shaped concave N-Gons without holes is quite easy. Triangulating complex N-Gons with holes, self-intersectiosn, etc. is one of the most difficult problems in computer graphics at all. And with difficult I mean it takes years to write a really good triangulator. After trying to make my own stable for many months I finally licensed FIST, which is probably the best triangulator you can buy. Its under development since almost 10 years and has an amazing 25k lines of code. 25k lines just for triangulating polygons. I think that says everything about how complicated it is to make triangulation robust.
Booleans are quite comparable in complexity. They look simple but they can cause tons of headaches. As triangulation they are also very prone to numerical problems.
Luckily there exist middle ware companies today which sell these high end algorithms.:wink: Even although they are not cheap.
Bye,
Martin