C++ Plugin Workflow
-
On 23/05/2013 at 13:49, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 13
Platform: Windows ;
Language(s) : C++ ;---------
Hi,I'm experimenting with making shaders in C++ and what that means is I'm doing a lot of:
try this value...try another value...try another value...etc.The problem is every time I change a value in my code I have to:
- Close C4D
- Make the changes to my code
- Compile it
- Launch C4D to see the changesIs there a way I can compile my plugin without shutting C4D down?
Is there anything I can do to improve this work flow to make it less painful?-ScottA
-
On 23/05/2013 at 18:12, xxxxxxxx wrote:
Nope. You can recompile while C4D is running but you will still need to restart C4D so that the updated dll is registered.
What I typically do when wanting to play with values in the code is create temporary description or gui elements for them. I even have development draw code that can be switched on and off using a checkbox. This way, you don't have to go through the process as often.
-
On 24/05/2013 at 01:51, xxxxxxxx wrote:
Actually, on Windows and if you're debugging in 32 Bit, you can use Edit & Continue.
Pause your debugging session, make the changes to your code, and continue. The changes are compiled on the fly and Cinema continues with the changed code.
On OS X or when debugging in Windows with 64 Bit, there is no such thing.
-
On 24/05/2013 at 08:15, xxxxxxxx wrote:
Thanks,
When I use the Edit & Continue method. It does work in 32 bit mode.
But I'm having a lot of problems stopping it when I do this.
When I stop the compiler. Everything locks up. And I have to open the Task Manger and force V.S. to shut down!
It sort of looks like VS is trying to undo itself a couple of times before it locks up. Almost like it's going through the changes I made to the project while it was open. Before it locks up.I don't know if this is related or not.
But when I pause the compiler (Break All) while debugging. A new page opes in VS with a warning about can't find symbols and a .dll.
I can't post the exact wording because while the thing is running I can't copy the text of this page.
There is a checkbox on that page that will probably change some setting. And I don't know if I should enable it or not. And if doing that will fix the lockup problems?Is there a certain preferred way that we should stop the debugging session?
-ScottA
-
On 24/05/2013 at 08:23, xxxxxxxx wrote:
Howdy,
Can you create a user defined variable for that value so you can change the value on the fly within Cinema 4D?
Adios,
Cactus Dan -
On 24/05/2013 at 08:39, xxxxxxxx wrote:
Originally posted by xxxxxxxx
Can you create a user defined variable for that value so you can change the value on the fly within Cinema 4D?
I'm using that trick already for testing single values.
But I'm changing far too many variables for this to be a good solution. I'm rarely changing only one or two variables at a time.I think the Edit & Pause method will help me out a lot here. If I can make it stop properly.
-ScottA
-
On 24/05/2013 at 10:22, xxxxxxxx wrote:
Well I would NOT recommend to use "Edit & Continue" too much or at all...
It is 32bit only but 64bit is the standard today.
Of course it would be great if "Edit & Continue" would be work in x64.
For C4D only there may be available some other alternatives that will work only in x64 in a future.
But I am still working on it... -
On 24/05/2013 at 11:36, xxxxxxxx wrote:
I don't know what happened. But It stopped crashing on me and it seems to be working ok now.
One thing that might have caused a problem is the first time I used it. I had a c4d_debug.txt in my plugin folder. And maybe that was just too much for the Break All to deal with?
I don't know. *shrug*
I might have also executed a "compile" after making changes to the code too. That could have been the problem. !Embarrassed[URL-REMOVED]Yeah. It would be nice if it worked in 64bit. But I don't mind too much that it's only 32 bit.
I'm only using it to test changes in my shader maths to see what it does to the colors and shapes of my shader plugin. And 32 bit mode won't hinder my testing for this.Here's the workflow I'm using now:
1- Start debugging in 32 bit mode (The green arrow icon in VS)
2- Create a new material and assign my shader plugin to the color channel
3- Pause the debugger using Break All (The pause icon in VS)
4- Change my code in VS
5- Press the debugger arrow icon which is now a Continue command (DO NOT manually build the code again!). It will recompile the changed code automatically.
6- Execute the Render Materials command in C4D to update the changes made in my plugin codeRepeat steps 3-6 as needed.
This is less painful than opening and closing C4D every single time I change the shader code.Vielen Dank,
-ScottA
[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.
-
On 25/05/2013 at 09:51, xxxxxxxx wrote:
Hi, as far as I know, you need 64 bit only on special occasions when writing ordinary plugins. 64 bit has several advantages though, when it comes to heavy work, like rendering.
So I use this approach - 32 bit and edit and continue. What a giant leap forward compared to writing Python plugins.. I really like C++ and C4D.Now, you do not need to explicit start C4D. Just fill in the properties under Debugging, Command, Command Arguments and Working Directory. When you press F5 in Visual Studio to run your plugin, Cinema 4D will automatically start and open the file indicated under Command Arguments.
-Ingvar