Blender uses Sphinx to generate its API, which IMHO is a really clean and attractive design. Personally, I never liked doxygen very much. I’m guessing what you’re referring to moreso is the code itself. It has been brought up before to have more consistent naming since right now it’s a mixture of camel case, underscores, etc., and the issue with the overall structure. Unfortunately, doing this would break existing scripts so it’s not feasible until breaking backwards compatibility is allowed (idk when that will be…).
From that link posted, it looks like your naming conventions are similar to C (see Blender source for examples), which is why you want to remove the dot operator because C is not an OOP oriented language nor does it have the concept of namespaces. This isn’t the preferred approach with Python since it’ll make the code look redundant unless you’re using a purely procedural paradigm or something.
it may not look like it here, but I do respect the works you guys have put into Blender very much
the devs have done an amazing job with supporting the evolution of 3D and integrating Python into the mix
(I have no disrespect towards Blender overall)
I only have disrespect towards the docs, as for me im particular, as I am a visual learner and need to see structures rather than put them together from a chain of links (I actually had to make a txt document so I could comprehend the structure)…
I only see a mess of stuff just thrown here and there in which the only way to get to it is by searching or clicking a link…
I did mention it needs ALOT of work
the functions you can click on (that actually have a link to the page, or more-so actually have a page created for them) will glow blue when you hover over them.
(I’m only one guy working on about 6 large projects and 7-8 small projects, so things are bound to be unfinished)
ok, doxygen does have an attracive dsign, but it’s missing ALOT when it comes to structure…
it’s basically just a stack of pages thrown out on the table…
where’s the class tree that shows priority?
where’s the structure that shows you references so you don’t have to click from page to page?
where’s there anything relating to a nice clean structure to reflect that clean look of the page?
that’s my issue.
this was kindof a second topic: (sorry about my autism here)
take into account that you’re only reading/writing model file data, which is all these scripts are used for.
I’m just doing this so it’s easy to understand (everything is provided as is, no dots with hidden possibilities which only exist to add complexity)
tbh, I don’t know too much about C… I can barely read the language
UMC is automated, so you don’t need to go through a crap-load of work and learn a bunch of crap just to import a file. XP
I’ve just recently added a pointer system for binary files so you can track the location of structs (another recent addition) easier.
(the file data I work with is basically GPU-RAM data)
and another thing…
you don’t need to go back and tell the interface a new object was created (it’s a cancelling automation of the process)
oid = ugeSetObject() # defaultly named "Object0"
oid2 = ugeSetObject()
ugeSetObject(oid) # backs out of the automation
ugeSetObjectLoc([0.0,0.0,0.0])
this is useful if you have a file which needs a list of objects created first before it can fill them
the naming of the functions is meant to keep things simple for noobs.
ugeSetObject:
uge (prefix for future compatibility)
Set (I/O >> interface)
Object (data type)
ugeSetObjectLoc:
uge (prefix for future compatibility)
SetObject (prevent noob confusion or function mis-matching)
Loc(ation) (shortened name, which does the obvious)
if it was easier to go further, I would, but I don’t want the names to be too long, so I’m only resolving the places of quick confusion.
(the rest of the confusion is taken care of in the function descriptions on my page, and minorly taken care of in the func.doc)
^ I’m also building an IDE to help noobs even more:
^'m still working on intellisence notifications which displays the func.doc like VS2010 with extra info as to what the function returns.
also, everything is visually interactive (click a function or data, it highlights it in the displays), so you know WTF you’re doing with what you’re working with
(I intend to integrate this with UMC later on)
sorry if I’m making Blender look bad… I’m just doing what needs to be done (what the devs should be doing)…
(and hoping to inspire Blender devs to do the same)
don’t get me wrong, I love Blender
it’s much better than that messy “3D Studio”
relying on Blender’s BC… they kinda messed up on the first release of 2.5 where they used classes and went more complex…
I’m not even gonna bother with model importing now as they just made it waaay too complex to use there.
(I gave it a try, and threw it out the window where it exploded) lol
you can still use BC but it’ll have to be done like my SES format where the interfaces needed are completely different:
SESv1 - recursive list model format
SESv2 - scripted model format (the file is a UMC script)
(that’s how UMC works: format1 > *.SES > format2)
my next release of UMC is aimed at both BC and FC, as I don’t intend to change the functions (only add new functions for new discoveries).
modifications may take place on side features though, such as the export functions:
Old:
while ugeBonesExist(): # (iterates through the active rig object)
New:
while ugeBonesExist(False): # (iterates through this bone’s children only)
I’ve looked into Panda3D once before, and yes, I agree:
no priority
little description
it’s just simply an outrage, where Blender’s API is only a nighmare
I don’t really care about the look, so long as I’m informed about the structure and everything needed to know about the code (in visual reference).
I can cope with walls of text (which is difficult for me to understand, though not impossible), so long as there’s a structure.
I see, you want a more visual representation of the relationships. That would help actually. I think Sphinx has a inheritance diagram extension to do that.
I find it strange that you don’t know C (writing is one thing but you can’t even read it) yet are referring to structs and pointers and “GPU-RAM data”, and then you go on to criticize the Blender devs.
What is UMC? A Python IDE? Your own model format? It sounds like you’re trying to roll your own object-oriented system or recreate Blender’s DNA/RNA system.
Reading that thread you posted, you violate so many programming principles like YAGNI, NIH syndrome, etc.
most of my knowledge about a pointer system was passed down from C# devs and compaired with some C++ devs
I really have no interest in C(#/++) or any other compiled language as I have no interest in a compiled program
Python seems to be one of the fastest interpreted languages due to it’s optimized structure, though it’s not exactly RAM friendly…
UMC can be compaired to blender only for it’s I/O system, the acronym stands for “Universal Model Converter”.
the only way to describe this program is that it’s fully extendable:
scripts (model, animation, image, …, code I/O)
libraries (extended/shared interface for scripts with more control over UMC’s interface)
plugins (extended features such as automated script updates or UMC’s GL viewer)
mods (small modifications before updates (offers a customizable interface and allows user feedback on features before they’re implemented))
tbh, UMC was developed entirely by my own logic.
I don’t know much about alot of principals which is probably why they’re violated…
more-so, I’ve put this thing together out of the troubles I had with other programs, and made it work.
the current release is pukable (SESv1 being a structured list of lists as the main format, which is highly inefficient), and can’t do much other than import basic models, keeping their bone data for export. (it doesn’t have a decent support for animation)
the future release will do everything mentioned above and will allow SOME modification to the model (such as recalculating and adjusting normals)
the new interface is designed using classes instead of a structured list, and is also designed to allow modification without any affection to the functions provided for users.
to prove this, I’m currently re-writing the old interface to support the new functions, yet still support SESv1’s inefficient format.
so yea… everything here can be called “my own knowledge”, though it’s put together from the verified knowledge of others…
for even more of a twist, my autism can be called a gift, aside from being a hinderance…
back in HS, I was basically writing complex algorithms without even taking the classes for that type of math…
I havn’t even taken a class for Geometry as I’d failed Pre-Algebra 3 times… (I graduated at Algebra 1)
(the work was easy, but I was just physically slow and couldn’t finish it with the other work I had to do)
so yea… I surprised my Pre-Algebra teacher with Geometric equations she couldn’t help me with.
(almost all of my math is pretty much self-taught from Python)
now-a-days, I tend to literally dream in code and am working on structures even more complex than UMC’s (or should I say UGE’s) sophisticated algorithms.
(try something along the lines of my future analog (not binary) game system, paired with AII (Artificial Interactive Intelligence))
^ DARPA is already working on analog computing (with binary externals), so I’m not afraid to mention my ideas
some things though (simple things) still puzzle me though as I don’t understand their terminology and fail to comprehend them in my work…
yes I’m calling myself smart and stupid
I have no idea where I get my knowledge from, unless my brain just grows it >_>
in comparison with UMC and the 2 programming syndromes you listed:
NIHS - I’ve most likely violated this as I’m branching off and doing my own thing with UMC and it’s terms of support for expension
reason:
a scripted model impoer system:
I boast about needing 50% to 70% less code than Blender,
and with Python as the language, offer a simpler scripting experience than other interfaces
media formats (images for example):
to support importing images, UMC relies on Python, and PIL as an internal support would be a nightmare to update.
you could integrate PIL as a library for UMC only if it would work outside of the interpreter…
so you’re kinda stuck having to script every image format unfortunately,
though you have the advantage of UMC’s file system which can do formats of custom byte-widths
(such as bf(5) >> 0x3F80000000 == 1.0), so there’s not really much loss when it’s made easy to re-write.
YAGNI - I don’t believe I’ve violated this as everyone (6 communities) love the idea of a much simpler scripting interface specifically for model conversion.
(almost everyone in 2 of these communities uses 3DS over Blender, claiming that 3DS is a better tool)
^ I tend to believe otherwise >_>
and I’ve needed just about everything I’ve mentioned.
(that’s including the pointer system which makes it easier to track binary data)
^a few BrawlBox developers can verify binary data being easier to handle with pointers, though I don’t agree with them using C# as the preferred language…
also, I’m not re-inventing Blender’s DNA system… I have a completely different system which uses a 2-sided interface…
what this means is you can give the interface PRE-transformed or UN-transformed (GPU-RAM) model data.
formats like Collada *.DAE use PRE-transformed data
here’s a few pictures for UN-transformed models: (no transformations applied)
I pretty much just search Google to find any API references which I do not know of. One way or another, it either directs me to tutorialsforblender3d.com or the official Blender API – both of which are incredibly useful. I think that the main problem I encounter is understanding why on earth certain API features are grouped in certain areas in the API (maybe someone brighter than me decided it was more appropriate to be listed there) and API features which are deprecated or simply do not work.
