Riptide 'Pro' - wish-list, testers, etc.

[soccerrprp]

hi keith,

sounds great! i don't have nearly the experience/knowledge that most have here, so certain that I would not make a good tester for you, though interested. :)

One thing does come to mind and that is OBJ sequence importer/exporter.

good luck! love your plugin!

Richard

[spedler]

Hi Keith,

1. Top of my list would be the ability to save and load presets for all the possible options. It would also be quite nice to be able to scale the imported object in relation to one of the existing scene objects - e.g. select a door in the scene then scale an imported character to say 80% of its height - something like that? Not really essential but saves importing a tiny or gigantic object you then have to scale accordingly, which can be awkward. I know you can scale an object already but sometimes you don't know what size it will be in relation to your scene.

2. I dunno... Riptide is so useful that a very small fee is not appropriate... would maybe $25 be what you had in mind?

[Keith Young]

@Richard - thanks for the input :beer: . Sequence import/export is on the list, but may or may not make it into the first release.


@spedler - thanks for your input as well...

Hi Keith,

1. Top of my list would be the ability to save and load presets for all the possible options.

Done (already implemented... several default/included presets. Still working on... unlimited user-expansion).

...It would also be quite nice to be able to scale the imported object in relation to one of the existing scene objects...

I'm not sure your suggestion fits into my plans very easily (will give it some thought), but one problem with the existing Riptide is that it always scales 'Up' on import and always scales 'Down' on export... the Pro version has options for that, which (along with presets) should help.

2. I dunno... Riptide is so useful that a very small fee is not appropriate... would maybe $25 be what you had in mind?

I don't have a fixed price-point in mind yet, so thanks for the input.

[Erik Heyninck]

I see a "pro" version as being in the first place handier to work with. How can that be done? Why is Riptide used? To import and export .obj to and from Zbrush and other apps.
So scale is indeed a great feature I think, but if it could act like a bridge between, say: Cinema and ZBrush, it would be even better. Kinda like the way Irfanview can open files and directly open them in an external editor of your choice. Not necessary, pure laziness, yes, but that's "pro".

Depending on what you offer, $25 would be basic

[BUZZFX]

Keith, not to take anything away from you. This Plug-In is a lifesaver for importing/exporting obj files but In my opinion, Maxon should have implemented a properly working import/export function for .obj files "within"*Cinema 4D a long time ago. It's been requested dozens of times on this forum and other forums, but so far it doesn't exist.

I think Cinema 4D is the last of the top 5 high-end 3D applications to not implement this feature within the core version. I think it's quite lame or lazy :( on Maxon's part to not add this functionality within the Cinema 4D core, and rely on other coders like yourself to create this plug-in and keep it updated.

I think it's great that you have created this plug-in and I look forward to future updates. :)

[Keith Young]

I don't want to get too far off-topic (and while I agree that it could use improvement), in Maxon's defense:

it's not uncommon for users to use/prefer 3rd-party import/export plugins (I know it's common in Max, not sure about Maya and others).
the options implemented in my plugin are (and/or will be) driven by imagination and user-input and not necessarily what might be considered 'proper' support for the format (implementation is open to interpretation/imagination).
I'd personally rather they spent thier time working on the core functionality of the app than worrying about details / features of any particular file format.
...I think I posted the above in another recent thread, so sorry for the repetition here and, of course that's just my take on things - I'm sure others feel the same as you do.

The only substantial concern I (you/everyone) might have is that... one of these days, I'll kick the bucket and/or cease to update the plugin for some other reason. This is a valid concern, to which I can only respond that (short of ceasing to exist, myself), I have no plans to cease support for the foreseeable future.

[Per-Anders]

I would say bring it into the import/export list. Paintguy - C4D has working obj import/export, but it doesn't handle groups and the point order can change on import, Riptide offers many more options and controls than the C4D one (in fact than any of the inbuilt ones that I know of for any app), and for me it's biggest advantage is that it doesn't reorder points on import (due to what I use it for).

[BUZZFX]

I would say bring it into the import/export list.

That's a great idea Per! that's the obvious place to look for it. :)

Well it's just a beef of mine and I do appreciate all of the time and effort you have put into creating this awesome plug-in. So sorry for being O.T. and carry on!! :)

[therealpepe1]

I use this for 3dsmax you my be familiar with it.
http://www.guruware.at/main/objio/index.html
I like the export presets for certain software I think it's genius. Possibly you could implement such a feature for import export.
My other suggestion would be to somehow fullproof the export and import of material I just can't seem to ever get it right.
Pe

[Keith Young]

I would say bring it into the import/export list.

I don't know if this has changed since then, but when I first wrote Riptide, it was an import filter plugin... problem was that C4D's built-in filename parser saw ".obj" extension and used it's own code instead of my plugin (ie. my plugin can't/couldn't "replace" the built-in code). That's why it ended up as a menu plugin.

[Keith Young]

Without too much comment, here's a teaser import screen shot:

http://skinprops.com/images/mp_sample2.jpg


...the sample .obj file was made up of:

- file named "dynhair_test3.obj"
- 3 mesh 'object' records (Mesh1, Mesh2, Mesh3)
- 3 groups (Hair_1, Hair_2, NewGroup)
- 9 line segments in Hair_1, 3 in Hair_2, 6 in Newgroup, but no line segments within Mesh2

The above image is the result immediately after import, with various (new) options set.

[Keith Young]

...you might not normally explode the line segments into a spline for each one - I just used that option to show off the full grouping options :). There are also options to split the splines up on a per-group or per-object basis, or as a sinlge spline object for the entire file.

[Keith Young]

Sorry Pe, I completely missed your post earlier...

I use this for 3dsmax you my be familiar with it.
http://www.guruware.at/main/objio/index.html
I like the export presets for certain software I think it's genius. Possibly you could implement such a feature for import export.

As mentioned above, Presets is already one of the new features. The Preset system should help cut down some amount of confusion, providing some basic default settings for some known Apps. It also offers handy set-and-forget functionality once users get more familiar with exactly what each option is/does and create thier own Presets.

My other suggestion would be to somehow fullproof the export and import of material I just can't seem to ever get it right.
Pe

You don't mention what issue you're having, so it's difficult to respond to this - the plugin does a decent job with .mtl file parsing (moreso with the changes in the most recent versions of the plugin). Aside from some finer details related to how .mtl files are implemented (see the docs), there's really only a few things to know about importing materials (all listed in the docs and various forums in multiple places)...

For materials to be imported:

1. there must be a "mtllib the_material_filename_goes_here.mtl" record in the .obj file.
2. the named .mtl file must be in the same folder as the .obj file you are importing.
3. for materials (and the .mtl file) to be loaded, the .obj file must also have "usemtl materialname" type records in it.
4. if the .mtl file lists texture files to be loaded for some materials, those texture files need to be somewhere within the "Texture Paths" C4D Preferences settings.

...obviously you also have to have the "Import Materials" option checked, but aside from the above basic requirements, they should be loading fine.

[lllab]

hi,

very nice idea for the pro version, i am in for this:-)

my wishes( i know are many;-):
1) a 64bit version!!!;-)
2) keep groups, and / or layers if that is possible( or convert layers to groups) maybe differnt options how to g structure file in import?
3) import cameras (if obj saves camera data-dont know)
4) keep names of objects ( seem to ba alraedy done:-)
5) import splines (seem to ba alraedy done:-)
6) import normal maps also correct if the object was mirrored in origin applcation (like the normalo plugin)
7) better material import from mtl, translate basic attributes(color, alpha, reflection, specular)

i would love to use obj as main importer but dont do it as all materials come in bad and the structure is very unoptimal at the moment, keping grouping hieraechies and layers would be extremyl helpfull!

thanks for this great import plugin, it makes c4d again even more worthy:-)
if some of the things mentioned in this thread will come i am in!

cheers
stefan

[Keith Young]

Hi stefan,

Some comments below...
1) a 64bit version!!!;-)

Noted (and planned at some point).

2) keep groups, and / or layers if that is possible( or convert layers to groups) maybe differnt options how to g structure file in import?

I'm not sure I understand this... one of the original reasons for writing Riptide in the first place was to support Groups... it's been doing that for years now :). C4D 'Layer' support is already implemented (see my example import screen shot, above).

3) import cameras (if obj saves camera data-dont know)

No camera data in .obj files.

4) keep names of objects ( seem to ba alraedy done:-)
5) import splines (seem to ba alraedy done:-)

Done and Done.

6) import normal maps also correct if the object was mirrored in origin applcation (like the normalo plugin)

As far as I know/recall, "Normal Maps" as a technique/process were invented long after the .mtl file spec, so there is no known/specified support for them (no normal map record in the file), but I'll look into that further. But I'm also not sure I understand the suggestion about how it should keep them correct if mirrored... can you expand on that any?

7) better material import from mtl, translate basic attributes(color, alpha, reflection, specular)

Sorry, I'm not following you again... Riptide has always translated basic color/alpha/specular/etc settings from .mtl files into some C4D supported fashion.

i would love to use obj as main importer but dont do it as all materials come in bad and the structure is very unoptimal at the moment, keping grouping hieraechies and layers would be extremyl helpfull!

Hmm... are you sure you've tried Riptide (http://skinprops.com/riptide.php) ?? :) (you can't just "Open" a .obj file, you have to use "Riptide->.obj Importer" found in the "Plugins" menu)

C4D's built-in .obj Import routines don't bother reading the .mtl file at all. Riptide has always read .mtl files...

It loads materials. It keeps groups. It lets you split the mesh up by groups (or materials or UVMapper regions, or not at all). And dozens of other options. C4D Layer support is being added (already implemented) in the new Pro version, along with Spline and Object name support, among other things.

Thanks for the input - I'm anxious to hear any further details you might have on any of the above.

-Keith

[LemonNado]

Right now..... import multiple .obj. In two way's. One is to store a name-sequence number .obj pile. The other would be to simply select multiple .obj files in the file browser and those should be imported. Both should be grouped under a null to prevent flooding the object manager window.

Reasonable for me would be anything from 50 to 100$. It would save work, so I pay for it. For the usual gang of free loaders... there is the free version (for which they could donate...).

If you need someone who could chase a few hundred .obj's through the plugin and translate to German and Marsian then I'm in as well.

Cheers
Rainer

[lllab]

hi keith
sorry if somethings are alraedy in latest reptide:-) didnt knew that, i am on 64bit at the so i cant use reptide at the moment.

with normal maps i actually meant normal TAGS ,sorry. the somtimes come in bad in c4d, thats why there is the "normally"plugin. would be good if reptide would import them correct from first point.

i think it also depends from which application the obj comes:-)

it is very good news from the things you alraedy supported, import of layers will be very very cool!

so i just hope for an 64 bit versin- thats the most urgent for me:-)
thanks Keith!
cheers
stefan

[Keith Young]

...with normal maps i actually meant normal TAGS ,sorry. the somtimes come in bad in c4d, thats why there is the "normally"plugin. would be good if reptide would import them correct from first point...
i think it also depends from which application the obj comes:-)


Ahh.. yes, if there are vertex Normal records in the .obj file and you have the option enabled, Riptide does import them and set up a Normal Tag on the mesh (and they should be facing the right direction, relative to the Reverse Faces option being enabled or not).

In general, Normal Tags in C4D are less than useful. The Normal Tag doesn't update itself when new vertices are added or various other changes (at least in earlier versions - I hadn't done much testing with them in recent C4D versions), so I typically don't use them.

Since they are not normally needed by C4D, the only 'good' use for them is if some app properly exports them relative to some 'Smoothing' group or values prior to export. Those altered normals could them be used to override the runtime coumputed smoothing that C4D does if there is no Normal Tag.


it is very good news from the things you alraedy supported, import of layers will be very very cool!

Just to clarify, the .obj file format doesn't have any kind of 'layer' info in it (it has Object, Group and Material groupings, but no similar 'Layer' grouping). So the Layers I'm referring to are the ones implemented in C4D R10 - which lets you group various tags and other elements in the OM into Layers which can be hidden/shown, enabled/disabled in various parts of the interface. I currently have options to generate new C4D Layers for:

- Group Tag and all Selection Tags being generated as group selections on any/all meshes created.
- Region Tag and all Selection Tags being generated as region selections on any/all meshes created.
- Selection Tags being generated as Material Zone selections on any/all meshes created.
- Texture Tags on any/all meshes created.

...Riptide can generate lots of these tags (depending on how many textures, groups, material zones and regions a mesh has), so this makes it easy to clean up the interface by hiding them when you're not working with them.

[rsquires]

Just got to say thank you for this great plugin.

One of my big headaches was working with Silo and C4D where the scale just kept wigging out. Silo's viewport is set much smaller than C4D and this was always a headache, with tiny models coming back into C4D from Silo even though I set import and export options, or so I thought. But no longer with Riptide. It just works! I am very happy camper

One thing. Why do the materials have a luminance channel when there wasn't one in Silo. It brings in stuff with the correct colour but a white luminance channel. Not a problem as such but would like to see if there's a way around this. I only had 3 different textures but if this was more then it would take time to turn them all off.

I'm off to donate to your site

all the best

rich

[Zendorf]

Hey Keith,

Just another vote for importing obj sequences and you could count me as a happy customer. I have given up trying to get fluids mesh sequences into C4d manually, as it is just too limiting trying to load a sequence of huge meshes into the scene at once.

If your plugin could load meshes on the fly like the Next Limit import plugin that would be a big selling point!

[lllab]

ok keith,

you are the obj expert:-)

reagrding normal maps, i know they are not fien to work, but when importing nurbs data they are still very important to some users. like for cars etc, when they need the exact smoothing, not an averaged one. i also seldom use them but some customers want them to be used.

cheers
stefan

[Nyvann]

Thanks for Riptide. I would absolutely pay something like 25$ or so for this plugin. Maxon should be paying you. Actually, paying you makes me feel more secure about the future of using C4D and Zbrush. Shame on Maxon, fix cloth too, GRRRR. My request would be a Tips/Do's and Don'ts...just a little addendum in the help that has pre-zbrush setup pointers or things to not-do. something along the lines of cmiVFX's zbrush->c4d tutorial video. :buttrock:

[Keith Young]

Hi Rich,

First off, I got your donation - thanks much!

...One thing. Why do the materials have a luminance channel when there wasn't one in Silo. It brings in stuff with the correct colour but a white luminance channel. Not a problem as such but would like to see if there's a way around this. I only had 3 different textures but if this was more then it would take time to turn them all off.

Riptide has to map certain .mtl file records into a C4D-compatible meaning. In this particular case, it maps 'Ambient' values in the .mtl file to 'Luminance' values in C4D materials. In earlier versions of the plugin, I think I was pretty much always setting some default level in the Luminance channel, but the newest version(s) now only enable the Luminance channel IF there are values for Ambient in the .mtl file.

Ambient records in the .mtl file look like:


Ka 1.0 1.0 1.0 <-- this would set the ambient/luminance color to white
map_Ka sometexture.jpg <-- this would define a ambient/luminance texture


...the .mtl files are simple text files, so you can open one up in a text editor and take a look... if it has 'Ka' records, then the resulting materials in C4D will have the Luminance channel enabled.

[rsquires]

Hi Keith

I am trying to get Silo to play nice with Riptide but unfortunately try as I might I cannot seem to get it to import the UV map.

I have unwrapped my object in Silo and create a UV Proxy. When I import it into Cinema using the default import method Cinema sees the UV's fine although it is very small in the viewport. Riptide does the scaling between apps better in my opinion but it doesn't see the UV map. I am not quite sure why this is but it's baffling me.

Does anyone who uses Silo, Cinema 4D and Riptide as a workflow have any suggestions. I am a bit stumped

all the best

rich

[Keith Young]

Hi Keith

I am trying to get Silo to play nice with Riptide but unfortunately try as I might I cannot seem to get it to import the UV map.

I have unwrapped my object in Silo and create a UV Proxy. When I import it into Cinema using the default import method Cinema sees the UV's fine although it is very small in the viewport. Riptide does the scaling between apps better in my opinion but it doesn't see the UV map. I am not quite sure why this is but it's baffling me.

Does anyone who uses Silo, Cinema 4D and Riptide as a workflow have any suggestions. I am a bit stumped

all the best

rich

Very odd. I'm not even sure what to guess at [ Edit: I assume that you do have the "Import UVs" option enabled... right? ;) ]. Could you send me a simple example file that shows this problem? typhoon [at] jetbroadband [dot] com

[MAN0]

is tehre a chance to support more filetypes? (like 'smd' or some other game related filetypes)

[Keith Young]

is tehre a chance to support more filetypes? (like 'smd' or some other game related filetypes)

That would be a different/separate plugin. I'm not opposed to writing plugins for other file types if the specs are available and there's enough demand for them, I just haven't researched them much yet.

[Keith Young]

@rsquires (and everyone else):

I got your file - thanks. The problem turned out to be some structural / re-organizational changes changes made in the v1.8 update, which broke the facet (polygon) parsor in some cases. See this thread (http://forums.cgsociety.org/showthread.php?p=5125829#post5125829).

[Magnus3D]

I also wish for a 64bit version, it would be great! because it seems the current version isn't at all working in Cinema4D 64bit which is a problem when one uses your plugin often.

/ Magnus

[Keith Young]

Thanks for Riptide. I would absolutely pay something like 25$ or so for this plugin. Maxon should be paying you. Actually, paying you makes me feel more secure about the future of using C4D and Zbrush. Shame on Maxon, fix cloth too, GRRRR. My request would be a Tips/Do's and Don'ts...just a little addendum in the help that has pre-zbrush setup pointers or things to not-do. something along the lines of cmiVFX's zbrush->c4d tutorial video. :buttrock:

Sorry, I missed your post earlier... thanks for the comments and take a look at this thread (http://skinprops.com/ext/forum/forum_viewtopic.php?147) if you haven't already.

[Keith Young]

I also wish for a 64bit version, it would be great! because it seems the current version isn't at all working in Cinema4D 64bit which is a problem when one uses your plugin often.

/ Magnus

Noted. I've already got an empty partition set up on my drive and have a line on the compiler, I just need to save enough pennys to buy the 64-bit OS. So it's coming, I just can't say when just yet.

[tcastudios]

, I just need to save enough pennys to buy the 64-bit OS. So it's coming, I just can't say when just yet.

Folks, for Gods sake, click that donate button.

Cheers
Lennart

[Magnus3D]

Keith: Thank you very much, that sounds promising :) if i had any money i would use your donate button to help you buy XP64, but i'm broke.

To add a comment to Nyvann's suggestion i'd like to suggest that you include presets for common applications, both import and export to help users with good settings. Also that the users could create their own presets and share them with others.

/ Magnus

[Keith Young]

Teaser Images to follow:

Filter (general) Options...
http://skinprops.com/images/mp_filter.jpg

Presets (all but the "Import From Torque" are built-in defaults... the Torque one was added later using the "Create" button)...
http://skinprops.com/images/mp_presets.jpg

Mesh Splitting Options...
http://skinprops.com/images/mp_meshsplit.jpg

Spline Options...
http://skinprops.com/images/mp_splines.jpg

Materials -> Channels Options...
http://skinprops.com/images/mp_matchan.jpg

Materials -> Textures Options...
http://skinprops.com/images/mp_mattex.jpg

C4D Layers Options...
http://skinprops.com/images/mp_layers.jpg

Document Options...
http://skinprops.com/images/mp_doc.jpg

[Keith Young]

The reason the "Delete" and "Update" preset buttons are ghosted is because the "Last Used" and "Default Import Options" presets are 'locked'. The rest can be deleted/updated as desired and new ones can be created at any time (no limit is imposed).

The presets themselves include every option shown above, including scaling and Suggested Path (for textures) and every other option you see.

[Keith Young]

BTW, I have English, Japanese and German covered, but am still looking for people willing to do French, Italian, Spanish or other translations.

[chi]

ummm ok so I might be way off on these suggestions as I've been out of the 3d world for close to 7 months now...but how about some handy comparison tools? like say you import on object and made some changes to it and are about to export and want to verify that you have messed up point order or made any inadvertent cuts or something like that...so maybe a tool were you can set a reference file that is used to validate the mesh to be exported...or would that just be useless...or maybe a little counter built right into riptide for quads tris and ngons before export...once again i really have no clue...I haven't touched anything in a long time...but I love riptide and want to see it better!

[WDupre]

Riptide was a godsend to me with my work, it's one of the primary reasons I continued to use C4D rather than switch over to something that is more .obj friendly, and I use it on a daily basis so It will be a no brainer for me to purchase the pro version when it comes out.

the one thing I can think of that I would like to see is a batch import/export ability, so I can Import and export a bunch of .obj files at once.

[vinced]

Hi Keith,

i have some problems with the obj-import of n-gons, maybe this is an issue you could adress with your Riptide-plugin.

Please have a look at this thread to see what my problem is exactly:
http://forums.cgsociety.org/showthread.php?f=47&t=634942



Greetings
Dirk:)

[Keith Young]

Hi Keith,

i have some problems with the obj-import of n-gons, maybe this is an issue you could adress with your Riptide-plugin.

Please have a look at this thread to see what my problem is exactly:
http://forums.cgsociety.org/showthread.php?f=47&t=634942



Greetings
Dirk:)

Hi Dirk,

I looked through all the linked threads... if this is a problem (I'd need to see a sample .obj file to test it), then it's something Maxon would need to fix, since my (most recent and all future) plugin uses Maxon's internal triangulation code.

As mentioned in one of the other threads, you should enable viewing the triangulation of Ngons in C4D view/filter options - that would let you see/show what's happening to those. The images shown so far don't really tell the story and/or can be misleading.

The other option that Michael suggests is to use the triangle/quads export option from MoI - so that would be a work-around, if it is in fact a triangulation problem in C4D (from my perspective/impression, C4D does a really good triangulation job, so I'd need to see a simple example of this issue before commenting further/differently).

[vinced]

Hi Keith,

you can find the files here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=1620.9

Below the image.
File is called:
cube_fillet.obj

[Keith Young]

Thanks.. I missed that link earlier.

Ok, I downloaded and looked at the mesh and the triangulation done looks perfectly reasonable (ie. optimal). I'm guessing if you exported from MoI using the triangles/quads option, you'd end up with that same triangulation.

In other words, if I was trying to come up with the best possible triangulation solution for those Ngons, that's exactly what I'd want.

The only issue I see is that those non-planar Ngons are causing some issues with BodyPaint, using some uv-projections. But as far as I can tell, that's just due to the actual characteristics of those (non-planar) Ngons.

For example, try this:

import the file using Riptide with "Import Ngons" enabled.
switch to BodyPaint
select all faces
switch to the Projection tab and click on "Box" mapping
if you zoom in and look across the bottom, you'll see some apparently open-ended mapping (kinda like 3-sided polygons, with one end open)
with all polygons still selected, go select the "Functions -> Remove N-gons" menu option.
look again at those uv-polys.. the open ends got closed.
...I'd note that "Cubic" mapping works correctly (as expected), but most of the other mapping modes have issues similar to above.

[Keith Young]

...I take some/most of that back (hey, I just woke up :) ).

An optimal triangulation of those Ngons would result in 2 quads (an upper and lower quad, along the horizontal), instead of one center quad with a triangle at each end. Knowing that, I'd now be curious how MoI would triangulate it if you used the triangles/quads export option.

That may or may not fix the BodyPaint mapping issues, but either way, it's something Maxon would need to address.

[helluvapixel]

Oh, I dunno how about a Collada option for the PRO version? At least for geometry. Then perhaps a way to swap between OBJ & Collada within Riptide.

Staying within Riptide OBJ umbrella, what about a restructuring tool to consolidate or create groups to represent parent/child relationships?

Also, what about implementing QEMLOSS alogrithm for mesh reduction, and have it recompute vertex normals?

[ionicdesign]

Good point, jclark073. If possible, adding Collada would be a great plus to the plug-in, and based on threads here and elsewhere, there are lots of people who would be very interested in that functionality.

[Keith Young]

Thanks for the input Jason. My comments below...

Oh, I dunno how about a Collada option for the PRO version? At least for geometry. Then perhaps a way to swap between OBJ & Collada within Riptide.

Collada would best be handled by a whole new/separate plugin - I don't think being able to covnvert from one to another format would justify the added complexity of having both code paths in one plugin.

Having said that, Collada is an interesting format, but there may already be others (Maxon? some other 3rd Party? both?) working on it. If we don't have it by the time I get some free time, I'll look into it again.

Staying within Riptide OBJ umbrella, what about a restructuring tool to consolidate or create groups to represent parent/child relationships?

I'm not sure I know exactly what you mean by this, but it sounds similar to some ideas I have for once I get the multi-group support implemented.

Also, what about implementing QEMLOSS alogrithm for mesh reduction, and have it recompute vertex normals?

Aside from special-case conditions (phong edge breaks, etc), C4D automatically handles vertex normal computations (ie. they don't need to be supplied/attached to the mesh). A mesh reduction is interesting, but that might be better as a separate plugin as well.

I don't mean to pooh-pooh any ideas/suggestions - all are welcome - I'm just trying to walk the fine line between Complexity (ease-of-use issues) and Flexibility (feature-rich functionality), related to importing/exporting .obj files.

Thanks,

Keith

[Keith Young]

Good point, jclark073. If possible, adding Collada would be a great plus to the plug-in, and based on threads here and elsewhere, there are lots of people who would be very interested in that functionality.

Hi Michael,

See my comments above - I think there may already be C4D Collada efforts underway. If not, I'll look into it once I get the time.

[helluvapixel]

Hi Keith,

Regarding groups and hierarcy. Depending on the OBJ, and how it is grouped it would be neat that Riptide would interogate the OBJ on import and show you how the hiearchy is. Then if you chose to you could adjust the structure prior to the import and Riptide would restructure.

I see a lot of value adding QEMLOSS if people are using OBJ as an intermediate fromat from CAD models.

Perhaps I am outside your scope, but as you may read between the lines I am giving feedback from my workflow using PolyTrans and C4D. Having Riptide as a OBJ->Collada type tool could be very useful for people that want to interoperate with CAD and other programs without purchasing an application like PolyTrans.

[Kuroyume0161]

I can't see a reason to go OBJ->COLLADA. COLLADA's greatest asset (no pun there) is in its ability to support lights, cameras, hierarchies, rigging/skinning, morphs, animation, physics - none of which are encapsulated in the OBJ file format. OBJ only supports meshes and splines.

[Keith Young]

As far as a 'grouping hierarchy' within a .obj file...

There's kinda not one, unfortunately. Polygons just belong to 'some group', but there's not really any terribly reliable information in the file that tells you how the groups relate to each other.

The only thing that hints at a hierarchy is the fact that polygons can belong to more than one group (although Riptide does not currently allow or support this). So, for example, you might have an Object Manager type tree that looked something like:


human (null)
hip (mesh)
abdomen (mesh)
chest (mesh)
neck (mesh)
head (mesh)
leftEye (mesh)
rightEye (mesh)
etc.


...if there was an option (similar to the current "Preserve Hierarchy" Riptide export option) that would combine those mesh names into a list of groups that the polgons belonged to, you'd see group records in the .obj file that looked like:

g human
g human hip
g human hip abdomen
g human hip abdomen chest
g human hip abdomen chest neck
g human hip abdomen chest neck head
g human hip abdomen chest neck head leftEye
g human hip abdomen chest neck head rightEye

...sort of 'implying' a hierarchy of groups within the file (the leftEye polygons would also be part of the head group, the neck group, the chest group, the abdomen group and the hip group).

[NOTE: The "Preserve Hierarchy" Riptide export option does create similar group names/lists, but may put colons instead of spaces between names]

When importing/reading a file that had polygons belonging to mulitple groups like that, you could try to determine an 'implied' heirarchy from the list of groups and link them into the Object Manager tree appropriately based on that (creating Null objects for any groups with no polygons).

While that may (or may not) be easy enough to envision and discuss, implementing that in practice has many mine-fields.

there's no verbage in the file format specification that talks about hierarchical relationships between groups at all - only that polygons can belong to more than one group...
...because of the above, the 'order' the group names are listed on a group record (or just within the file) doesn't 'actually' mean anything relative to how the groups might be related to one another...
...meaning that they might be listed in any old order from some other application (within the file and/or on any particular group record - for example "g head neck hip leftEye human chest abdomen")...
...meaning that even if you knew all of the above and/but assumed or knew ahead of time that the file was written such that there was an implied hierarchy in the group names, parsing them into those groups programatically is going to be non-trivial. :D
...so, that's what I'm up against. Implementing multiple-groups-per-poly (also known as polys belonging to more than one group) will require substantial changes to my code - it's planned, but will take some time/effort - divining some implied hierarchy from those multiple group names is another level of complexity on top of that, but I'll burn that bridge when I get to it ;) .

[Kuroyume0161]

I tend to agree with Keith on this. OBJ groups are ambiguous for constructing a hierarchy. How about something simple like an external (eh-hem) phi-le? This is how Poser imparts a hierarchy onto a Wavefront OBJ automatically. As a matter of fact, you could simply support the Phi format (which is very simple) - PhiBuilder is a free tool for this. Sounds like a plan to me. :)

[Keith Young]

Yes, a Phi-file reader would indeed handle that particular (Poser-centric) problem, but it adds another tool to the process (end-user ease-of-use issue).

The example I used was probably a bad choice - in reality, you typically don't want a humanoid/Poser mesh to be split into multiple meshes in C4D, the mesh is easier to deal with (doesn't exhibit shading issues) as a single still-welded mesh, with group selection tags. I just used that because it was an easy to understand example of a 'hierarchy'.

[EDIT: As an aside, Poser would choke on that type of grouping anyway :). What you typically see for multi-grouping in a Poser .obj file (depending on export options) would be something more like the name of the figure pre-pended to each group - "g Figure2 head", "g Figure2 neck", etc.]

The more generalized situation (say a scene that had ground and shrubery elements, some complex of buildings, that had windows->frame->glass, doors->doorknob->hinges->panel, pictures->frame->image->glass->hanger, desk->drawers->drawerhandles, etc. or an atomic model with the elements and/or connectors or any other type of Object Manager tree) is the situation I'm looking to see if there's some automated solution for.

If it requires some tool or user-manipulation, then they might as well be doing that after the import, directly in the Object Manager. The only way to achieve some gain/benefit would be:

a) no tool or user-manipulation is required (if some hierarchical relationship can be devined from the .obj file itself) or...

b) if a tool is used to produce some hint information that can be re-used (so the user doesn't have to keep doing that manipulation/tree-building).

...in the case of Poser type humanoid models, a Phi-file approach would fulfill the second option nicely, since those meshes generally use a standardized naming of groups and those groups are generally always in the same hierarchical order (so you could use the same .phi file or choose between some small number of them). But this is less true for any other type of scene (conglomeration of mesh objects in some .obj file) that the plugin might encounter.

Anyway, my first goal is to re-structure the plugin to handle multi-grouped polygons to begin with (since this is allowed/specified in the wavefront .obj file format specs). When I first wrote the plugin, I was under the (false) impression/understanding that it wasn't allowed, so I didn't allow for it in the code. Now I need to figure out how to back-fit that into the plugin, which already has many options for dealing with and is somewhat driven by groups (splitting the mesh by group - or not, sorting faces on export by group - or not, etc.).

With all the various options and tracking the plugin already does, I've kinda built my own monster that I now have to tame :). Once I get that in place (and/or as I do that), I'll see if and how I might be able to implement any hierarchical relationship between groups.

[Keith Young]

...[EDIT: As an aside, Poser would choke on that type of grouping anyway :). What you typically see for multi-grouping in a Poser .obj file (depending on export options) would be something more like the name of the figure pre-pended to each group - "g Figure2 head", "g Figure2 neck", etc.]...

Going slightly OT here, there ARE reasons for me wanting to support multi-grouped polys, and one in particular is in fact related to Poser...

Most apps don't really apply any specific meaning or usage to 'groups' within the .obj file, but Poser has a few.

it uses group names to determine the polygons affected by 'bones'. Poser uses a separate .cr2 (character) file that contains all the bone and linkage information (along with material attributes and other things related to what makes up a character). Each bone within that file references a case-sensitive group name within the .obj file that defines the polygons used for that bone.

[this is why I said above that Poser would choke on the naming I used above... polygons can only belong to one bone at a time (as far as I know, at least - that might be worth looking into for other Poser-rigging reasons....).]
Poser also has a 'Group Editor' built into it (not as easy as making groups in C4D, but it's there never-the-less). A separate use for groups within Poser is that you can have Poser Magnets (or other deformers) only affect specific groups of polygons.
...now, when you combine #1 with #2, the 'parent' group might be the name of the bone (ie. "head", "neck", "chest", etc). But within some group, you might want to create a sub-group of polygons that is affected by some magnet (ie. "g head top-lip").

To give a real-world example of this, when I first wrote Riptide, I was starting to play around with developing a humanoid figure for use in Poser. However C4D's built-in import/export of .obj files was causing me no end of heartache, because of what it did to my material zones and groups (and re-ordering vertices and everything else...). - So I wrote Riptide.

Anyway, once I finally had a reasonably complete figure, I started rigging it and setting it up for use in Poser. At this point, I was trying to figure out how to go about making various facial morphs (eye blinks, phoenemes, tongue movements, etc.). I was fairly handy with Poser Magnets, so I proceeded to use them to create dozens of facial and other morphs for this new figure... note that in some cases, this required me to create new 'sub-groups' of polygons using the Poser Group Editor (so I could manipulate the lips without affecting the teeth - both of which are in the 'head' group, for example).

As I created each morph, I also saved that particular set of magnets to the library - in case I needed to re-create that morph at some point. What I had not really thought through was 'how' to retain these new sub-groups of polygons for future use... Poser did in fact export the modified mesh with these sub-groups listed on the group records, but Riptide had already been written and did/does not support multi-grouped polygons (D'oh!).

Needless to say, I went on to make additional changes to my mesh in C4D, losing the sub-groups in the process and so I was unable to re-use those magnet presets to re-create all those morphs that relied on those sub-groups, without going through the process of re-creating the sub-groups in Poser (which was a pain in the ass to do in the first place :sad: ).

Sorry for the rambling - I just wanted to give a real-world example of what multi-grouped polygons are and what they can be used for.

[helluvapixel]

That's interesting info Keith, I've not delved that deep into the format. OBJ is my last choice after FBX, Collada, VRML2.

[Magnus3D]

Is there a price set yet for this ? or when will there be ?

/ Magnus

[Keith Young]

Is there a price set yet for this ? or when will there be ?

/ Magnus

Hi Magnus,

The price has not been set yet - development got side-tracked a bit for some other things, but I hope to get back on it and finish it up soon. My current thoughts is that it will be priced under $50, but I just haven't yet decided the price.

[helluvapixel]

My current thoughts is that it will be priced under $50, but I just haven't yet decided the price.
More importantly, have you decided on the feature set?

[Keith Young]

The feature-set is still evolving, but you can see much of it in the dialog images on the previous page.

[Magnus3D]

Thanks for your reply Keith :) i understand you haven't had a chance to give it a price yet, as soon as you have decided and you're ready, please let us know.

/ Magnus

[Magnus3D]

Keith, what do you think about adding a phong angle setting thingy in the import dialog in RipTide Pro ? it would help when you import models and create presets for different applications. Another thing that would be nice is to have the ability to export and share presets we create for applications.

/ Magnus

[Keith Young]

Keith, what do you think about adding a phong angle setting thingy in the import dialog in RipTide Pro ? it would help when you import models and create presets for different applications. Another thing that would be nice is to have the ability to export and share presets we create for applications.

/ Magnus

Hi Magnus,

Thanks for the suggestions - I'll consider them for a future update.

Keith

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.