dast

I understand what you mean, but I still cannot imagine a workflow for this. The whole point of creating seams is to unwrap what is "inside" the seams. In your example you create a seam and only want to unwrap a portion of the polygons. Why don't you then simply create seams as boundaries of the polygons you want to unwrap? The cut in a loop fashion is because YOU select the seam to be a loop. The whole point of Seamilar is to create seams, but it's up to you to create them. You are not limited to loop selections.

Thanks for that, might come handy. I will investigate the symmetry again. I might have broken something. As for the WIP 3 crashing. Yet another interaction issue I suspect. For next WIP I have completely stepped away from the current concept. Resolving all these possible interactions issues is just a nightmare. Could you please elaborate on this?

Thanks for the feedback so far, everyone. As explained at the start of the thread, the final imlementation will dictate which version(s) of Cinema 4D can be supported. This due to differences in availability of features in the SDK versions. The easiest for me would be to only support the latest version, leaving quite a lot of you in the cold. Another approach would be to ask the potential users of this Seamilar plugin what version of Cinema 4D they are using (and thus would like to see supported). In order not to clutter this thread with version requests I have created an online poll (as it's a free one, there might be some adds and banners, sorry about that). The reason for this poll is to know if it is worthwhile to spend time trying to support a particular version. It doesn't make sense to support a version if no one is using it, while maybe skipping a version which is most popular. Depending on the poll result I hope to be motivated to solve the obstacles for said version(s). I haven't limited the number of choices per vote, but I would like to ask to only pick one version. (The more versions that need to be supported the less features will make it.) EDIT <link to poll removed>

How embarrassing! I uploaded the wrong file, sorry. Correct version has been uploaded now.

As mentioned, WIP 3 contains a new drawing implementation. Reading through the developers forum and blog, I gathered as much information as possible and did my best to let Cinema perform most of the drawing, reducing CPU calculations from within the Seamilar tool. It's still not a lightweight process, but CPU time is now only required to perform the original drawing, while re-drawing is kept to a minimum. I'll leave out the technical details. I understood that many didn't appreciate the fact I stored data into their objects, and as was proposed I created a new tag to behave as a data container. While support for this new tag was rather easily implemented, most of the time was spent on solving all the possible interactions (undo/redo/user deleting tag/etc ...). After a few weeks trying to get all interactions under control, I still haven't managed to correctly handle the removal of the tag on an active object while the Seamilar tool is active. All goes fine, until the user performs undo/redo. Workaround is thus to switch to live selection tool, or to another object before removing the tag. As the current code to handle all these interactions is becoming too complex I am realizing I am probably heading into the wrong direction. So, I'll release the most stable state of the plugin as WIP 3, before rethinking the whole thing and providing it in a next WIP. There is currently one big drawback, which I still need to find a workaround for: I am using the Cinema 4D internal unwrapping function. But for this to work a BodyPaint3D Texture View window needs to be opened by the user, at least once during the lifetime of the Cinema 4D session. Confirmed by MAXON developers to be by design, not a bug. Sadly, they didn't provide any function to call the opening of this window from within a plugin. So users need to open it, manually. EDIT <link to wip 3 removed> Some technical details for those wondering what goes on behind the scene, when looking at the console: The original python plugin consisted of just a single tool plugin. To get things done as it is now, I needed to implement: - the original tool plugin - a window plugin (to show the colored UVs) - a tag plugin (to contain the needed data) - a scenehook plugin (for handling the optimized drawing) - a message plugin (for handling the interactions) Luckily for the user, all this is just a single plugin file

Thanks for the feedback. It's the drawing of seams and colored polygons which requires quite some CPU time. A more efficient drawing has been implemented and will be available in WIP 3.

@arail try WIP 2 instead. People have been reporting issues with getting WIP 1 to show up. I have now removed this older file. Working on final steps of WIP3 now, but I guess it will not be ready this year. Regarding a Mac version. I was going to think about other platforms as soon as the WIP mode is completed. One idea I had was to purchase a cheap, second hand Mac mini in order to compile the plugin, as I am not fond of distributing my sources. This would then also allow me to perform first level tests on every released platform version. Something to think about later on, as for now I 'd like to focus on getting the plugin completed first.

As I have been too busy with another plugin, I haven't had time to test out the updates I made to SPETI. However, I don't want to let the users waiting forever, so I release here the unfinished version 0.6 Note that due to changes in Python SDK, this version is only supported in R18.028 and up. <removed obsolete file>

Good to hear.

Some people seem unable to get the plugin loaded, I don't know what the issue is. I have looked for the missing win_dll.cpp and cannot find this file on my system either, still the plugin loads OK for me (Win8.1 and R18.028). In the meantime I have build WIP 2 using the R17.053 SDK. I have tested on R17.053 and R18.028, on both versions the plugin is loading and working. The only difference I noticed so far was that the "terminator" dots of the seams are dots in R18, while these are squares in R17. Minor cosmetic difference. R17+ (Windows only) <obsolete file removed>

There are 2 locations where plugins can be installed, I tried both and they work OK for me. There are no redistributables required, all is available with R18 SDK. Have you restarted Cinema 4D after copying the plugin to its destination folder? Can you open the console (Shift-F10) and see if anything erroneous is logged? "It doesn't show up" By that I assume you mean that Seamilar is not listed in the plugin menu? Or is it listed, but greyed out?

Symmetry has been implemented. Demo videos below Simple symmetry: https://youtu.be/Knve0B60hos Multi symmetry: https://youtu.be/Btks5qDzyLs

At first I though "Why would I do that?". I mean, storing the data into a (hidden or visible tag) is just more work than storing it into the object. And in the end, when the object is saved to disk, the tag is saved along, so what's the difference? However, if I store it into a new tag and make it visible, the user could remove it ... getting rid of the data if s/he wants to. So, maybe not a bad idea after all.

As usual (for those familiar with my other plugins) I will provide versions of the plugin as development progresses. Notice that due to technical reasons the plugin does need to store data into your objects. This means that once you save the scene the additional data is present in your objects on disk. As long as you don't save the scene only the objects in memory are altered. Be sure to have a copy of your original objects before using this plugin !!! During my testing I have noticed that sometimes Cinema4D can not unwrap/relax the UVs as it can not obtain a handle to the UVs. This seems to be a limitation of the SDK and something I am still trying to resolve. As a workaround you then should open a Bodypaint TextureView window and drag-drop the UVW tag from the object manager into the TextureView window. For now this "work in progress" is R18 and windows-only. <obsolete file removed> Enjoy!

Thanks for sharing.

Thanks. Seamilar is more intended for interactive process, where you create the seams. As such, I didn't foresee starting from selection tags to perform the unwrapping. As it currently is implemented, when you activate the plugin with edges selected it will automatically read these and "convert" them to seams, creating the different UV islands in the process. For technical reasons I now only unwrap (relax + realign) when the user interactively selects a seam. I will have to add your suggestion to my to do list.

Since last time I had a look at implementing my own UV view, in order to allow for a visual feedback on the colored UV islands. Here is the result, playing around with an old character I had created for C4DCafe's "Inner workings" challenge (2006). The navigation seems a bit jerky, apparently related to the capturing software, as the navigation is fluid when not recording. In this demo video I open the new UV View window next to the BodyPaint Texture Window, for comparison, as well as due to limitation of SDK. I am still looking into this in order to find a workaround. Note: I probably didn't choose the perfect seams, but this was a simple demonstration. It already shows that a proper symmetry selection would be quite useful. I might have to raise that topic's priority on my to do list. So far, the implementation requires features available since R16, so unless further obstacles I would be aiming to release for R16 and above. Support for previous version would be possible, but with crippled undo/redo functionality.

@maliohammad I am a C++ software developer by trade, so the jump from Python wasn't the issue. In fact it was the other way round when I starting writing plugins in Python, last year. By now I still don't know the language by heart and extensively need to refer to its documentation. Same for MAXON's SDK , and unfortunately their Python and C++ SDK are not a simple one on one mapping. Which means I basically had to rewrite the whole original Seamilar plugin before being able to add the new UV unwrapping features. Took me nearly two weeks (full time), and then another week to figure out the unwrapping. Luckily I had already spent most of the time doing the research while implementing the Python plugin ... just waiting for MAXON to catch up with the Python SDK ;-) Looking back, I better had started with C++ from day one, I wouldn't have wasted waiting for a working SDK. @smibrand If you have some character models to share, sent me a private message as I would be thankful to have a more complex model to play with. @arail I don't know what Modo provides as UV functionality, we could discuss your needs, and see if I can fit these into Seamilar. For now I am mostly focused on getting a stable "framework" implemented. All "fancy" features (symmetry, auto unwrap, ...) will have to wait.

Thanks to all for the feedback so far. Thanks. Hence the name of this plugin. Haven't looked at 3D Coat since over a year, but I can say that it was a revelation to use the demo and a great inspiration to make my own tool. I am collecting ideas as we speak, as I am not to fond of BodyPaint's TextureView window. If possible I'd like to display a better UV representation, but I know the current SDK is limited in that area.

Working on the next version of this plugin (see here) I will probably retract this Python version from public, as well as stop any support for it.

[Edit - Note: this thread should be located in the "Programming - C++" section of the forums. It ended up in the "Python" section by accident during one of the forums reorganizing sessions] For the original plugin version I would like to refer to this thread. A year has passed since the implementation of that Python plugin, and while I wanted this Seamilar plugin to do more than currently has been released, the Python SDK held me back. With the release of R18 MAXON provided additional bodypaint functionality in it's Python SDK, and I finally could implement the full version of the plugin as I envisioned it at the start. Or so I thought. Unfortunately, MAXON's dev support confirmed that the added functionality didn't work, so I was back to square one. Instead of waiting on a fix from MAXON, I went ahead and digged into the world of C++ plugin development, as this SDK didn't suffer the reported problems. A few weeks later and I have this "concept version" running. More development is required before it reaches a stable release version, but it already shows it's potential. No release date available yet. As for the supported Cinema 4D versions, this will depend on the needed functionality in the final version. One drawback of this being a C++ plugin: while the python plugin (being a script) is platform independent, a C++ plugin needs to be built (compiled and linked) on PC and on Mac separately. EDIT: If you want to know more about the progress of this plugin, feel free to browse through the many posts that have been written since the birth of the plugin, to its current state.

I have another suggestion for house rule: If a questions is posted and answered, the least decent thing the poster of the question could do is report back, provide feedback on the given answers. Regularly (but not most of the time) you'll see questions asked, with one or more solutions provided ... and never hear back from the original poster. The users who did take the time to post their solution would appreciate feedback if their answer was useful or not. It might help them to formulate their solutions differently in the future, in case it didn't fit the original post, etc ... More than once did it happen where I spend quite some time to explain a solution, with detailed text and screenshots, some attachments of xpresso setup or some python code ... and never heard back. I don't keep these users in a black list or so, but when I recognize their user-id I tend to ignore their future posts. end of rant.

While I do appreciate the suggestion, I don't fully agree. It seems obvious having an explanation provides for a better understanding of the solution. But not everyone is gifted with the possibility to clearly bring over their intention, and provide a "readable" (understandable) explanation. Additionally, there is the language barrier for non native English speakers. When I provide an answer, I often need to look up words, translation, etc ... This hinders my explanation. For some, providing comments is just second nature and comes fluently. For others it turns out to be a task, more of a chore actually, which takes up quite some time to pen down. (This "simple" reply did cost me 16 minutes in total to write down) So, yes, I am all for providing detailed comments on solutions by the poster, but it should not be mandatory.

Glad I could help.

Here is a scene file with userdata setup and python tag to control the groups. The reason for sharing the scene file, and not simply the python code, is that the userdata IDs are important. So with only the code and no userdata to refer to it would be hard to understand. Hope this helps. Python Show-Hide UserData.zip