On 22/03/2015 at 18:39, xxxxxxxx wrote:
Cinema 4D Version: R14
Platform: Windows ;
Language(s) : C++ ;
I'm fast heading towards a point where I need an ogl access point for my plugin. Does anyone or support, have a basic setup or example that I could develop off the back of? It can either be via the SDK's factory stuff, or direct ogl routines itself. I would probably prefer the standard ogl way as I know a little on that already, and there's a lot more references on the net to study than the sdk's.
That said, I'm happy to keep it all in the sdk family if it is easier to implement and be more portable from pc to mac. It would still need to be reasonable speed-wise though.
I'm only after a starting point. Nothing more than something that shows that it's working (something like a polygon draw, or a change in background colour). It needs to do a couple of things:
1: needs to draw into a user area (specified by coordinates/screen position, but I can probably take care of that) and preferably without having to go gpu->cpu->gpu (I've been informed that this would really only slow it down, and that it shouldn't really be necessary?)
2: would be great if I could still draw basic elements over the display (i.e. using something like DrawLine() inside the user area's draw function) but I can probably just as easily draw them in ogl itself
3: would prefer something that's 'simple' to implement, i.e. would like something without external libraries unless they're simple to setup, and can be happily used on both pc and mac without too much setup nonsense
4: extending on point 3, needs to be cross-platform for pc and mac. Perhaps a good reason to use the sdk over standard methods?
I've had an ogl display in the past, and I still have that lying around, but I could never get it to draw properly. I can do normal ogl stuff in a Windows dialog, but not a Cinema dialog - it only ever drew tv-like noise. Trying to work the rest of this out myself though is becoming a bit beyond my skills. A proper working starting point would be a big help here! Cheers,
On 24/03/2015 at 01:17, xxxxxxxx wrote:
as you know Cinema 4D is a DCC application and the API is designed to extend that application in specific ways. Cinema 4D is no real time application framework and the API does not provide any functionality to support the creation of own OpenGL windows etc. There may be some OS specific ways to get this running but this is no longer related to the actual API and not supported.
The question I would like to ask is why do you think you need to use OpenGL itself. What do you actually want to achieve?
On 24/03/2015 at 05:07, xxxxxxxx wrote:
I need a 'display' that I can fill with polygons and/or point data. As far as I know, we can't have our own viewport in a dialog (or can we?). I'm trying to find a way without having to make an OS-specific dialog because so much work has already gone into making a native Cinema one! I'd chosen ogl as well because it's a ready-made-system and I don't need to do the developing of it. And using cuda rules out those on ati systems.
It doesn't need to be a zbrush 'billions of polys in realtime' display (it's nothing to do with sculpting/painting/rendering anyway), but it really needs to be more superior than a cpu based solution. If there is an alternate solution I'm all ears, but using ogl makes far more sense as it ticks all the boxes I need, and it leaves the cpu free to run other concurrent processes.
Re the api - what's all the undocumented ogl factory for? I can make an ogl context using the api - but how do I make it current? Why would there be a context creator if there's no way to draw a context into a dialog (or layout gui element)?
I'm hesitant to ask too many questions as I don't want to flood the forum with 'me' - I bother users and support here enough as it is! But, this is a pivotal part of the plugin - it won't stand without this display. So I'm trying to find a way (a hack is fine!) or something 'outside the square' to get it started. Strangely enough I'm fine with the ogl drawing, but I don't think I'm skilled enough to get the initial display started in the Cinema dialog. Anything I've tried to date just draws noise. And hence - anyone with any ideas?
EDIT: update to text
On 24/03/2015 at 08:04, xxxxxxxx wrote:
my best suggestion is:
1- download embree "for viewport shading embree is realtime"
2- then paint it in a Bitmap inside your user area
On 24/03/2015 at 10:30, xxxxxxxx wrote:
while you cannot create a custom viewport in a dialog the next best thing would be to use an own BaseDocument that is rendered via RenderDocument(). The resulting BaseBitmap could be displayed in a GeUserArea in that dialog. This is pretty much how the interactive material preview is done. This solution may not have the speed of a "real" viewport but depending on what you want to do it may be sufficient. Also, this is the only solution we can recommend.
Undocumented functionality in the API is only used internally in Cinema 4D and should not be used by third party developers since the functionality can be limited, unstable or experimental. Some elements of the API are simply not built for you.
On 25/03/2015 at 19:36, xxxxxxxx wrote:
I've taken a look at Embree Mohamed, but in typical fashion it won't work on my machine. There's always something.
I think I had wondered about the RenderDocument() too Sebastian. But just to double check I went back to an experimental scene I had saved to refresh my memory on viewport performance. A single polygon object with 1 million polys in the normal Cinema viewport runs at about 3.4 fps. When I up this to 4 million polys, rendering in software mode takes 2-3 seconds per frame. It's just far too slow. I don't need billions (I'm sure someone would like to try..!), but I definately need a few million.
Can we make our own BaseCustomGui derived object? What's the use of a window handle as far as the sdk is concerned?
On 26/03/2015 at 02:08, xxxxxxxx wrote:
BaseCustomGui is the base class for custom GUI elements. In typical Cinema 4D fashion you can create own custom GUI elements based on CustomGuiData and iCustomGui. CustomGuiData is the custom GUI type and iCustomGui is the actual GeDialog to display your custom GUI. So this custom GUI elements can only do the same things you can already do in a custom GeDialog.
On 29/03/2015 at 17:42, xxxxxxxx wrote:
Hm. You're not making this easy for me Seb ! I'm going to have to have a think about how to overcome this. I have a few things up my sleeve, but most of them still require the ability to draw to screen I think.
Are we able to access bitmap data directly? That is, the underlying pixel data array? So, not bmp->GetPixel(...) etc, but the actual array of pixel data itself? What's the data container type and what's it's structure (RGBA/ARGB)?
On 30/03/2015 at 01:55, xxxxxxxx wrote:
you can edit a BaseBitmap not just with GetPixel() / SetPixel() but also using GeClipMap.
The BaseBitmap class does not provide raw access to the underlying data structures. The fastest way to handle the content of a BaseBitmap may be to use GetPixelCnt() and SetPixelCnt(). But also these methods copy the bitmap data in to the given buffer.
For questions no longer related to this thread's original topic please open a new thread. Thanks.