These tools would not be for the "pro's". They can stick to Blender or whatever they like.
These inworld tools would be for people like me, who like to build but still want a result that is somewhat up to par, and not as if it is build by a toddler using his building bucket. And that without the need to study weeks/months to get somewhere (like with using a mesh body in SL or Blender).
I do not think any in-world buiding tool should be polylist mesh based because polylist meshes are by nature counterintuitive both for humans and for computers.
Here's a simple example of what I mean, a circular plane with a curve resolution of 24 and a diameter of 2 m (I hope Gyazo images are permanent here, if not, I'll have to find another way to host them):
If we define this as a polylist mesh, the vertice coordinates are:
0.2588185 -0.965924 0 0 0 0 0 -1 0 0.4999999 -0.8660234 0 0.7071081 -0.7071083 0 0.8660234 -0.5000001 0 0.965924 -0.2588185 0 1 0 0 0.965924 0.2588185 0 0.8660234 0.5 0 0.7071083 0.7071083 0 0.5000001 0.8660234 0 0.2588185 0.965924 0 0 1 0 -0.2588185 0.965924 0 -0.5 0.8660234 0 -0.7071083 0.7071084 0 -0.8660234 0.5000001 0 -0.965924 0.2588186 0 -1 0 0 -0.965924 -0.2588185 0 -0.8660234 -0.4999999 0 -0.7071084 -0.7071081 0 -0.5000001 -0.8660234 0 -0.2588186 -0.965924 0
(You can calculate them yourself if you don't believe me). That's just the data for positioning the vertices in 3D space. Add the UV coordinates, the normals and the triangles between the vertices and you end up with a lot of bytes to describe such a simple shape.
More to the point here: this is not how we think. A shape like this is not a bunch of dots we need to connect, it's a circle.
Even more to the point, that's how a computer like to think too. A computer computes, that's how it got its name. Calculating a circle is child's play for any 21st Century cpu. And then it has to add those dots along the circumference because the poor idiot savant gpu can't only handle straight lines but that's easy for it too.
Digression - but an important one - there's been a lot of talk among some SL creators about automatically generated LoD models. How is the computer supposed to do that if this is presented as a polylist mesh? Realistically, all it can do is remove vertices. A 75% reduction down to 16 vertices gives us this:
Not too bad but hardly ideal either. It's the best the computer can do though. Unless you tell it it's a circle that is. Once it knows that, it can space those 16 vertices evenly around the circumference, no sweat.
---
This is a very simple example of course and it's only 2D even, but I think it still illustrates the difference between datalist based and procedural geometry.
There are several method for genrating procedural geometry. Some of them (such as fractals and metaballs) may be easy on the cpu but not very intuitive for humans - at least not if we want total control over the result, others (such as CSG) can be very human fridenly but too hard on the computer but there are still several both would be very happy to handle.
The prim system as Bar-Zeev created it, only uses three methods - sweeps, lofts and extrusions - and very simplified implementations of them to generate all the basic prim types. According to him that is. To me it seems to be all about sweeps and extrusions with no lofting in sight. Add 14 (if I counted right - there may actually be fewer) very basic modifers and you have all the shapes the prim system can produce.
Upgrade the system with a bit more elaborate takes on the basic principles and a handful of carefully chosen modifiers and we're we have an in-world building tool that is almost as easy to use as the current prim system but far more flexible. And that's just the start.
But the bottom line is that I believe the concurrency numbers are made up.
