PixelPlow Render Farm for Cinema 4D
PixelPlow Render Farm for Cinema 4D


Cafe Contributor
  • Content count

  • Joined

  • Last visited

  • Days Won


C4DS last won the day on January 16

C4DS had the most liked content!

Community Reputation

52 Excellent

About C4DS

  • Birthday 06/04/1970

Profile Information

  • First Name
  • Last Name
  • C4D Ver
    18 Studio
  • Location
  • Interests
    Electric guitars, Radio controlled electric airplanes, 3D, Video editing

Recent Profile Visitors

2,298 profile views
  1. The whole concept has changed. See my previous posts, as well as the demo video of WIP 4. The Seamilar Tool is now just a selection tool. While the Unwrapper tag does now all the automated unwrapping. However, while you usually would use the combination of the two, I didn't want to force this workflow. User can now use any selection tool to unwrap. Additionally, user can now also use Seamilar Tool for edge selection (without wanting to unwrap). The "disconnection" of Seamilar Tool and Unwrapper Tag, means that the user now manually needs to add the tag to an object for this to become the target for drawing and unwrapping. This manual action is what I referred to in my post -when I introduced the new concept- which might still change in the future. Other users liked the idea, so I left it for what it was in WIP 4. Regarding a Mac version, there is a potential solution on its way, but I can only confirm after the deal has been completed.
  2. Symmetry has been fixed, will be available in next WIP. I agree that one axis might be enough, but not everyone builds their meshes with the same axis orientation, hence I provide all 3 axes. It's up to the user to decide which one to use, and to use more than one if wanted/needed. I am using the built in functions for alignment. It has an option to preserve orientation of the island, or to let Cinema 4D realign it. In next WIP I will provide this option to the user, but currently the preserve orientation was set to false (= do not preserve orientation), so if the result of Cinema 4D is not properly aligned, there isn't much I can do ... currently. Of course I could implement a better unwrapping/alignment/packing algorithm. But that might make the plugin a little more expensive ;-)
  3. Haven't found the time to work on this plugin during the week, so excuse the delay. As such I have only been focusing on finalizing the new concept, and testing as much scenarios as possible to fine tune the implementation where needed. Of course, this will not guarantee for an error free plugin. Actually, I know there are some issues with undo/redo, and that will be the next area to focus on. Unfortunately, this all hasn't left me the time to look into the symmetry which was broken in WIP 3 (and thus still isn't working). But that's another reason to keep people coming back ... A big thank you to @DrBluem for the callcommand hint. During the unwrap/relax I do now check if the function is successful, if not I assume the Texture View hasn't been opened once and I thus perform the aforementioned callcommand, and try again to unwrap/relax. If this second one doesn't succeed ... there's something else going wrong. Unfortunately, I still haven't found a way to hide this Texture View after it has been initialized, and haven't gotten any response from MAXON dev support on this whole issue. So, for now, I leave it up to the user to close the Texture View manually, if they want to. If all goes as expected it will only open once per session. Not a pretty solution, but good enough for a WIP. Again a big thank you to DrBluem for providing a mesh to play around with. Unfortunately, I still haven't found the time to use it in any of the video demonstration. Sorry about that. But the gesture is very much appreciated. Thank you. Seamilar II wip4.zip (available for R17, R18, Windows only ... I am still waiting for someone to sponsor me a Mac ) Feel free to report any issues (or positive feedback). I haven't checked with the latest R18 update as I am still with R18.028
  4. @bezo Thanks for reminding me of the Outline selection. I always seem to forget about that. I mentioned yesterday I was going for a new approach. It's an idea I had while finishing WIP 3 in a hurry. Since it needed quite a rewrite of the plugin to match the new idea, I figured it would be better to release what I currently had ... but releasing (even a WIP) in a hurry is never a good idea, hence the issues and crashes. With WIP 3 uploaded I could go back to the drawing board and start afresh. Well here it is: the new concept! With this I am going back to the original plugin being a "simple" selection tool. Just as it was in version 1. Another part of the plugin now handles the auto unwrapping, while the seam selection tool is just another way of selecting edges (see video). The idea behind this concept is that any selection tool now becomes a "seam tool", not just Seamilar, but also the native live selection, loop selection, path selection, ring selection, ... you name it. It should even work with selection tags you have prepared. Double click a tag, edges get selected and the plugin unwraps. For now, only a video demonstration is available. Plugin needs to be "polished" before releasing it in a hurry, this time. Note: This will probably not be the last change of idea/concept as I go along implementing this plugin. Currently, it's the tag assigned to an object which is responsible of triggering the drawing and uv unwrapping. I am not to fond about that, and will probably move the trigger to a more common place. This to avoid the need for the users to perform the setting changes on a per tag basis.
  5. 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.
  6. 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?
  7. 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.) http://www.easypolls.net/poll.html?p=587253bee4b03d07b92c8b23
  8. How embarrassing! I uploaded the wrong file, sorry. Correct version has been uploaded now.
  9. 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. Seamilar II wip3.zip 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
  10. 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.
  11. I have had this issue now and then (win8.1) when my video card's display driver crashes. I then need to do a hard reset of my computer. Just restarting windows is not sufficient as windows hangs while shutting down. I once upgraded to more recent drivers, and those crashed more often. So switched back to rather old but "stable" drivers. Haven't been able to reproduce the problem, but now and then the issue pops up. I suspect some OpenGL related issue. Not sure if all this is related to what you experience.
  12. @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.
  13. 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. SPETI 0.6.zip
  14. 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>