I have been following this topic in all three (!) forums since beginning and I'm really looking forward to the outcome of this topic.

I'd call myself quite a Matrix mutant, so just ignore me, if my question is completely off topic or bogus in this context. My expectation would have been the same as @Cairyn's.
Yet, there has always been this last sentence on the Matrix fundamentals page, which reads pretty suspicious to me.

[Local Matrix] = MatrixMove(op.GetFrozenPos()) * HPBToMatrix(op.GetFrozenRot()) * MatrixMove(op.GetRelPos()) * HPBToMatrix(op.GetRelRot()) * MatrixScale(op.GetFrozenScale) * MatrixScale(op.GetRelScale())

Please note that the both scales are applied at the very beginning, so the local matrix is not the same as [Frozen Matrix] * [Relative Matrix]. This is necessary in order to guarantee that your local matrix always stays a rectangular system; distorted sy

I'm not questioning the correctness of this sentence. I'm just wondering if it may be related to this issue? And if one would maybe need to separate the scale from the equation and calculate it in correct order?

@zipit You are right. Forget my comment. I shouldn't have posted before my first coffee. Indeed I was triggered by the dialog not being closed, but then brain activity obviously went back to power save...

@zipit: Actually I wouldn't consider your code a solution to the problem. This is something, though I'm aware it's done quite often (and at least for quick tests I used such code myself for sure), that's a bit dangerous and most likely not supported by Maxon. The context owning the dialog, which is used to defer the status bar updates, does no longer exist after the execution of the script. It's basically a a zombie dialog performing the status bar updates. In my view, such code shouldn't be recommended, nor be used in anything that's released to the public.

Edit: While it's no good practice to leave a dialog open after script execution ended, my comment was wrong and stupid.

Thanks for validating my assumptions. Much appreciated.
Yes, I already have multiple code branches and for S22 my workaround looks as described. Because it doesn't hurt to insert the RenderData in this case, it doesn't even need multiple branches.
Thanks for looking into it, Maxime.

Is this going to be fixed in a future version?

If "always" means one in a million, then maybe.

@m_adam: Sure, I'm fine, and I hope, so is the entire SDK Team :)
Thanks for asking, Maxime.

I'm sorry, but here it's not.
I had tried the RENDERFLAGS_PREVIEWRENDER flag before. It doesn't change anything. At least not in my 22.116. And if I insert the RenderData as described, it works without RENDERFLAGS_PREVIEWRENDER flag.
But one has to be careful with testing. If the currently active scene has such flags set, too, then it may seems as if it works, while it actually is not working.
Is it documented somewhere, that this flag would be needed?

Cheers

In the script above I create the RenderData only for the purpose of rendering, so I doubt, it's a lifetime issue.

And in S22 it also works without inserting the RenderData, it's just the new filter flags that somehow seem to be taken from the active document's render settings. At least that's what I think based on further testing.

Hi,

I'm starting to feel pretty stupid. I'm trying to do a hardware preview render using the nice new filter options added in C4D S22.

My code looks roughly like so, here for use in Script Manager:

import c4d

def CreateDefaultRenderData():
    rd = c4d.documents.RenderData()
    if rd is None:
        return None
    vp = c4d.BaseList2D(c4d.RDATA_RENDERENGINE_PREVIEWHARDWARE)
    if vp is None:
        return None
    rd.InsertVideoPostLast(vp)
    vp[c4d.VP_PREVIEWHARDWARE_ONLY_GEOMETRY] = True ### THIS IS WHAT I AM ACTUALLY INTERESTED IN
    rd[c4d.RDATA_RENDERENGINE] = c4d.RDATA_RENDERENGINE_PREVIEWHARDWARE
    rd[c4d.RDATA_XRES] = 600
    rd[c4d.RDATA_YRES] = 600
    return rd

def main():
    docClone = doc.GetClone()
    rdPreview = CreateDefaultRenderData()
    if rdPreview is None:
        return
    rdPreview[c4d.RDATA_XRES] = 600
    rdPreview[c4d.RDATA_YRES] = 600
    bmPreview = c4d.bitmaps.BaseBitmap()
    bmPreview.Init(rdPreview[c4d.RDATA_XRES], rdPreview[c4d.RDATA_YRES])
    result = c4d.documents.RenderDocument(docClone, rdPreview.GetData(), bmPreview, c4d.RENDERFLAGS_EXTERNAL, th=None)
    if result == c4d.RENDERRESULT_OK:
        c4d.bitmaps.ShowBitmap(bmPreview)
    # insert render settings for comparison
    rdPreview.SetName('Test Settings')
    doc.InsertRenderData(rdPreview)
    c4d.EventAdd()

if __name__=='__main__':
    main()

I'm trying to get the VP_PREVIEWHARDWARE_ONLY_GEOMETRY flag to work.
The funny thing is, if I manually render the active scene with the render settings created by above script, I do get the result I want. But not so in the image rendered by the script.

... ... while writing these lines, it struck me. And indeed I can make it work by inserting the new RenderData into the cloned document and making it active. So my question is actually no longer, how to make it work. But more, why do I need to insert the RenderData into the scene? I mean, it's passed to RenderDocument separately and I doubt, I saw an SDK example explicitly inserting new RenderData for such purposes. But then again, as I said in the beginning, I'm starting to feel stupid and most likely I am.

Cheers

While the output is not as detailed and neat as with zipit's use of profile, this is what I like to use to measure timing of functions:

import time

g_timingInfo = ['']
def timing(f):
    def wrapTiming(*args, **kwargs):
        global g_timingInfo
        time1 = time.clock()
        ret = f(*args, **kwargs)
        time2 = time.clock()
        g_timingInfo.append('T %-8.2f ms : ' % ((time2-time1)*1000.0) + f.func_name)
        return ret
    return wrapTiming

def PrintTiming():
    global g_timingInfo
    if len(g_timingInfo):
        print '\nTIMING INFO:'
        for t in g_timingInfo:
            print t
        print ' '
    else:
        print 'No timing info'
    g_timingInfo = []

In oder to use it, you simply decorate a function (or multiple) with @timing and at a later point of execution you call PrintTiming() to get the accumulated results printed to the Console.
Like so:

@timing
def MyFunction():
    pass
@timing
def MySecondFunction():
    pass

def SomewhereInYourCode():
    MyFunction()
    for idx in xrange(100000):
        MyFunction2()
    PrintTiming()

I like the decoration approach, as it's fast to pour some "probes" into your code without modifying the actual implementation of functions.
Using module inspect you can easily beef it up by adding stack information or nice indentation of results based on call level.
And this may also give you an idea, how to build decorations yourself. Useful for all kinds of stuff.

Cheers