I started to learn programming language C ++.
To transfer data from Blender in Povray, we use files
My idea: to give up files.

How will it work?

#include <iostream>
#include <string>
#include <Python.h>
#include <fx.h>



int grab(int, char **) {
    PyObject *mName, *pModule, *pFunc, *pArgs, *pValue;
    PyObject *cResult, *pName;
    Py_Initialize();
    PyRun_SimpleString("import sys");
    PyRun_SimpleString("sys.path.append(\".\")");
    PyRun_SimpleString("from bimport import hello");
    mName = PyUnicode_FromString("bimport");
    char fName[] = "hello";
    pModule = PyImport_Import(mName);
    pFunc = PyObject_GetAttrString(pModule, fName);
    int i = 1;
    long nL = 5;
    PyObject* l = PyLong_FromLong(nL);
    pArgs = PyTuple_New(i);
    PyTuple_SetItem(pArgs, 0, l);
    pValue = PyObject_CallObject(pFunc, pArgs);
    cResult = PyTuple_GetItem(pValue,0);
    pName = PyObject_Repr(cResult);
    pName = PyUnicode_AsEncodedString(pName, "utf-8","Error ~");
    const char *Hello = PyBytes_AS_STRING(pName);
    std::cout << Hello << std::endl;
    Py_Finalize();
    return 0;
}
 ....................................
 ....................................
 ....................................

int main(int argc,char *argv[]){
  FXApp application("Povray animator","Test");
  application.init(argc,argv);
  Awindow* window=new Awindow(&application);
  application.addSignal(SIGINT,window,Awindow::ID_QUIT);
  application.create();
  if(argc>1) window->loadimage(argv[1]);
  return application.run();
  }

Also see the attachment.

I want to ask: I can anyone help tips?

Post a reply to this message

Attachments:
Download 'idea.jpg' (68 KB)

Preview of image 'idea.jpg'

Am 24.07.2016 um 19:31 schrieb LanuHum:
> 
> I started to learn programming language C ++.
> To transfer data from Blender in Povray, we use files
> My idea: to give up files.
> 
> How will it work?

Uh... I understand very little of what that piece of code is supposed to
do, most probably because of all the "PyWhatever" functions which, I
presume, are an interface to Python. So what you've written there is
probaly a wild mix of C++ and Python in C++-disguise.


I understand that your goal is to transfer data between Blender and
POV-Ray without using files (as in, "the things that get written to the
hard drive").

This is currently not possible, because files are the one and only way
to transmit the necessary data into POV-Ray (in the form of INI and SDL
files, as well as image map files and the like) and back out of it (in
the form of image files).

There is ongoing work to modularize POV-Ray enough so that it can be
called as a kind of library from other applications, allowing to bypass
the parser and the image file output, but that work is far from finished.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Uh... I understand very little of what that piece of code is supposed to
> do, most probably because of all the "PyWhatever" functions which, I
> presume, are an interface to Python. So what you've written there is
> probaly a wild mix of C++ and Python in C++-disguise.

Sounds kinda like
http://zulko.github.io/blog/2014/11/13/things-you-can-do-with-python-and-pov-ray/

https://github.com/Zulko/vapory

https://pypi.python.org/pypi/Vapory/0.1.0

etc.   search vapory + povray for more

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 24.07.2016 um 19:31 schrieb LanuHum:
> >
> > I started to learn programming language C ++.
> > To transfer data from Blender in Povray, we use files
> > My idea: to give up files.
> >
> > How will it work?
>
> Uh... I understand very little of what that piece of code is supposed to
> do, most probably because of all the "PyWhatever" functions which, I
> presume, are an interface to Python. So what you've written there is
> probaly a wild mix of C++ and Python in C++-disguise.
>


You do not need to understand it. I figure it out.
This is just an example of a model

>
> This is currently not possible, because files are the one and only way
> to transmit the necessary data into POV-Ray (in the form of INI and SDL
> files, as well as image map files and the like) and back out of it (in
> the form of image files).
>

Oh, that's interesting. Why is it impossible? There is no Povray scene?
scene = new scene  NO?
And where the parser loads the data?
Povray causes parser. The parser is doing what?
You can prevent the call of the parser, and cause my code.
My code does the work of the parser.
What is the problem?
It is only necessary to correct code PovRay:
if filepov:
bla-bla-bla
if fileblend:
bla-bla-bla

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
> > Uh... I understand very little of what that piece of code is supposed to
> > do, most probably because of all the "PyWhatever" functions which, I
> > presume, are an interface to Python. So what you've written there is
> > probaly a wild mix of C++ and Python in C++-disguise.
>
> Sounds kinda like
> http://zulko.github.io/blog/2014/11/13/things-you-can-do-with-python-and-pov-ray/
>
> https://github.com/Zulko/vapory
>
> https://pypi.python.org/pypi/Vapory/0.1.0
>
> etc.   search vapory + povray for more

No. They create .pov file. I know how it is better. I do not need it. Read my
previous post. Blender.so - python module.I will upload it in a blender file
with animation and immediately upload data to render.The process will take place
within the program at a rate of C ++

Post a reply to this message

Am 24.07.2016 um 20:41 schrieb LanuHum:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 24.07.2016 um 19:31 schrieb LanuHum:
>>>
>>> I started to learn programming language C ++.
>>> To transfer data from Blender in Povray, we use files
>>> My idea: to give up files.
>>>
>>> How will it work?
>>
>> Uh... I understand very little of what that piece of code is supposed to
>> do, most probably because of all the "PyWhatever" functions which, I
>> presume, are an interface to Python. So what you've written there is
>> probaly a wild mix of C++ and Python in C++-disguise.
> 
> You do not need to understand it. I figure it out.

"Believe me, I know what I'm doing"... now that's something that tends
to make me suspicious. I prefer to have at least some /basic/
understanding of what's going on.

(Also, if you figure it out, why do you need any help? ;))

> This is just an example of a model

That is a "scene file"? You intend to use C++ as a scene language?

Well, you'd need a C++ compiler to render a scene then. I doubt whether
that would be portable enough -- or even provide a reasonable speed
improvement over a parsed scene; after all, you'll replace a parser for
a comparatively simple domain-specific language with a parser for a
mind-bogglingly complex generic-purpose language.

Also, that would still not get you rid of files, since instead of
generating SDL files you'd then have to generate C++ files.

Unless -- and I suspect that's actually the case -- I'm completely
misunderstanding you.

>> This is currently not possible, because files are the one and only way
>> to transmit the necessary data into POV-Ray (in the form of INI and SDL
>> files, as well as image map files and the like) and back out of it (in
>> the form of image files).
> 
> Oh, that's interesting. Why is it impossible? There is no Povray scene?
> scene = new scene  NO?
> And where the parser loads the data?
> Povray causes parser. The parser is doing what?
> You can prevent the call of the parser, and cause my code.
> My code does the work of the parser.
> What is the problem?
> It is only necessary to correct code PovRay:
> if filepov:
> bla-bla-bla
> if fileblend:
> bla-bla-bla

That's how it /should/ work (and even just a naive picture thereof).

But parsing is only one part of the job -- you also need to start up and
manage the render threads, and control the assembly of their results
into an image. Not to mention photon shooting tasks, radiosity pretrace
tasks, and some such.

And the code performing that particular functionality (called the
"back-end"(*)) is still not well delineated from the render engine (aka
the "core"), the parser, and the user-defined function execution engine
(aka the "virtual machine", or "vm" for short).

It is even still interwoven with the user interface (aka the
"front-end"), or more precisely one particular piece thereof (known as
the "virtual front-end" or "vfe"); I like to consider that piece of code
my arch-nemesis in the quest for modularizing POV-Ray.

(*In POV-Ray 3.7.0, the delineation between back-end, parser, core and
vm was even worse than that, and the term "back-end" referred to the
entirety of all those modules.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Unless -- and I suspect that's actually the case -- I'm completely
> misunderstanding you.
>

Do not rush. I had no time to explain everything.
Till tomorrow. :))))

Post a reply to this message

We continue to
https://github.com/Lanuhum/Blender-C-
Seeking a memory leak.
If you decide the problem - I will continue. I'll connect povray with blender.
:)))

Post a reply to this message

Am 11.09.2016 um 22:06 schrieb LanuHum:
> We continue to
> https://github.com/Lanuhum/Blender-C-
> Seeking a memory leak.

The name of the repo is poorly chosen: Pasting the corresponding link
into plain text such as a mail, software that auto-detects links in
plain text may think the trailing `-` isn't part of the link (this is
quite obviously the case with Thunderbird).

I would recommend renaming the repo to, e.g., "Blender-Cpp".

> If you decide the problem - I will continue. I'll connect povray with blender.
> :)))

You're not very familiar with C++, are you?

One property of C++ is that there is no garbage collection in the
language itself, and you'll have to actively release all memory you
allocate. Thus, in the main() function,

    int main(int argc,char *argv[]){
        FXApp application("foxray",FXString::null);
        application.init(argc,argv);
        new ImageWindow(&application);
        application.create();
        return application.run();
    }

the `new ImageWindow(&application);` will allocate memory for, and
create, an object of type `ImageWindow`, but makes no provision to
remember the address of the memory allocated, so there is no way to
release the memory later.

You probably want to do something like this:

    ImageWindow myWindow = new ImageWindow(...);
    ...
    delete myWindow;

One memory leak eliminated. I'll have a look whether I can find some more.

Post a reply to this message

Am 11.09.2016 um 22:06 schrieb LanuHum:

> https://github.com/Lanuhum/Blender-C-

Some more comments:


All the PyObject* items in py2c.cpp:

First of all, you're using global variables, which you shouldn't use in
C++ programs. You should wrap all the stuff in py2c.cpp into a class.

Then, every time you set them to some value returned by PyWhatThe_Foo(),
you're receiving a pointer to data residing... well, /somewhere/. Nobody
knows. And, more importantly, given that it is /probably/ dynamically
allocated, nobody knows who is responsible for /releasing/ the memory.
And /how/ to release it. The <Python.h> functions may be striaghtforward
C code, in which case you need to release the stuff using `free()`. Or
it may be C++ code, in which case you need to release it using
`delete[]` (most certainly not `delete`; subtle but important difference
there). Or <Python.h> may provide a dedicated function to dispose of it.
Obviously you're not really sure or aware of this issue either, because
you never invoke any of these mechanisms.

There is some code at the end of parse_blend() that /looks/ like it was
intended to do the trick, but you commented it out. Worse yet, it
wouldn't even be sufficient.

*Every* time you assign something to one of these variables (and also
when the program exits), the previous content gets lost, and the memory
it pointed to remains in limbo: Your memory holes are legion.

What you (presumably) need to to is call PyDECREF() *every* time before
you *overwrite* one of those PyObject* variables.


You may want to have a look at boost.python, which seems to encapsulate
the Python API a bit better for use in C++, most notably allowing the
use of smart pointers rather than classic C pointers. Smart pointers
automatically release the data they point to when you assign a new value
to the smart pointer, or even when the variable goes out of scope.
(They're even smart enough to /not/ release data if another copy of the
smart pointer still refers to the data.)


PyName_AsName():

Same problem as above, but even worse: You need to pass the data out of
the function, so you can't just call PyDECRREF() on the data (if that's
even the proper way of releasing char* data returned by the Python API).
I would recopmmend constructing a std::string from it (creating a copy
of its contents), and call the adequate memory release function
immediately. You can then return the std::string, which will save the
caller from the task of pointer handling.


parse_verts():

You're using a vector<double> to store three coordinates. This is
inefficient: vector<> is designed to store dynamic arrays, /not/ what
mathematicians would call a vector. Instead, simply use:

    double coord[3];

You can leave the remainder of the function entirely unchanged.


parse_faces():

Same deal as above for the `face` variable.


ImageWindow:

Here you're solving the global variables the right way: By making it a
class, and working with an instance of it. /But/ you're falling short:
Your constructor constructs an assload of data using `new`, but the
destructor only releases three of those fields using `delete`. Also, for
some of the stuff you're creating I wonder whether you're ever properly
hooking it up to other stuff. Maybe it's a quirk of <fx.h>, but to me
every "new" without an assignment to its left-hand side (or something
else that stores its result value) reeks of a serious coding error.


ImageWindow::onCmdRender():

Beware that clock_gettime is /not/ portable.


Well, I guess that should suffice for starters. I shall warn you though:
I suspect you'll still have a looooooong way ahead of you, and I won't
be able to provide this type of support on a regular basis.

I don't mean to discourage you, but seriously: Do you /really/ feel up
to this challenge you have given yourself? This is supposed to evolve
into an interface between Blender and POV-Ray's render engine, right?

Post a reply to this message