"ingo" <nomail@nomail> wrote:

> If we had a struct specific for spheres, we'd still need to initialize it and
> declare a sphere with it to later be able to identify that one specific sphere.

Well ... yeah.  But there are nuances to that, I guess.

We initialize blob spheres with a strength, so clearly we have an extant data
structure for spheres and cylinders that we can use/abuse to hold "metadata".
There's also the matter of automating such entry into arrays vs manual entry.
For automation, we need "handles" to grab things by and place them into the
array.
If primitives were assigned ID's when they were parsed (let's ignore any CSG
hierarchy for now), then there would be at least that.  I can run a #for loop on
everything if there were a last_assigned_id keyword or a way to check for an
undefined id.  And that way nearly everything would have a unique id (again,
ignoring CSG)
Also, returning to the idea of having a point {} primitive or a whole
point_cloud {}, it would make it vastly easier to put a specific coordinate
location into an array if the ability to do something like
center {sphere <x, y, z> Radius translate, rotate, scale, etc...}
were possible.  As it stands, I'd have to go through a whole rigamarole to
figure out exactly where that sphere center ended up, before I placed the value
into the array.
Then a year and a half later, when I wanted to do the same thing, I'd have to
excavate that code, remember how it worked, if the HDD it was on wasn't dead,
..... etc.

> When I need something like that I use an external program to generate a large
> array with struct like data and generate the spheres from that with a macro
> loop. The index of the sphere is then the identifier. All sphere parameters are
> accessible and modifiable through the array. Multiple sphere types, like your
> isotopes, are then multiple type specific arrays. You could also put your
> metadata in an/the array.
>
> If we had structs, we'd put structs in the array(s) just the same way.

Yes, of course, there's (almost) always "a way".
And this was exactly the answer I was expecting to be brought up by - someone.

The point is, that it helps people, especially new users, accomplish a task,
quickly and relatively easily, without tearing their hair out and screaming "F
POV-Ray, who uses this stupid program?"
What you propose is certainly an option, but I have a disdain for detachable
include files that can get lost or undergo versioning chaos, and as we all know,
SDL is SLOOOOOOW.

So yes - putting everything into arrays is the way to go.  But the question is:
how do we initially _get_ everything into the array?

It's fine if you have coding experience, and have the forethought and
organizational skills, and discipline to make it all happen, AND you're starting
from scratch.  But if all I want to do is use a sphere in a union as an
attachment point or center of rotation, then every time I transform that sphere,
I have all sorts of things to keep track of and calculate.  If I can just "grab"
that Nth sphere out of the union and instantly have that <x, y, z> coordinate in
hand, then it makes SO many tasks 1000 times easier.

What happens if Pavel Rae posts a nice scene that's all spheres and cylinders,
but I want to use the same assembly as a mesh?  Forget about the actual
conversion to that data structure - I don't even have access to the point data
yet.

And that's what people want.  We don't have a modeler, we don't have a GUI - so
we need _something_ to make the end-user experience ... better - or else we're
not competing in the marketplace of ideas and features, and computer graphics
power.

I hate gift cards, because the representative value is locked into one purpose.
$20 on a Wendy's card doesn't allow me to buy $20 of gas if I need it more than
a fast food lunch.  Currency is easily exchangeable for anything.  And what I'm
suggesting is looking at the data that's in a scene file as currency, not
informational value that's locked into a digital gift card because "that's what
the user intended it for".

You know I'm not just idly complaining, or lazy, or unmotivated - but sometimes
I would love to just be able to accomplish a task in an afternoon or a weekend,
rather than over a 5 year period, because the informational tools that I need
are within reach.  I'm sure I've delved into topics that people with actual
degrees in computer science haven't covered, or at least not to the depth I've
explored them.  And while I've learned a lot, and am better for it, sometimes it
would just be nice to let an idea flow, and come to fruition without having to
start another PhD-level investigation into matrices, calculus, tensors,
statistics, floating point math....

All this is just to brainstorm ideas and potential approaches.
We could even have a separate parser for all I care, that can handle the
analytical and algorithmic tasks separately, and be run separately, so as to not
further complicate the central code base.

But having certain tools available changes everything.
Try to copy something without ready access to a photocopier, scanner, or cell
phone camera.
Boom - you're back in the 1970's.

And I understand.   We don't have a developer.  We have 30 years of macros and
include files to sift through, and vast libraries of unexplored routines that
haven't even been converted to SDL, let alone implemented in source.

I'm just thinkin' out loud.

Post a reply to this message