Does anyone have any experience selling Rhino models on turbosquid or similair sites?
I`m modelling stuff as a hobby, but certainly would like to be able to sell my assets. I could imagine NURBS are barely used in the entertainment industry these days, and objects like boats, jewelry and other product viz are mostly contract jobs. Still, I dont see why nurbs models cant be used in ADs, arch viz etc.
I have some experience with poly modelling and selling, but I do enjoy working with Rhino much more.
All in all I`d love to hear any suggestions, market stats, file format advices, well everything
well as someone who works between Rino and 3ds max I would say that unless you can export a model from rhino with a proper flowing quad mesh then selling models to people who are doing Vis work would probably be difficult and slippery slope.
As you probably know, quad modelling has the benefit of topology that allows for proper UV mapping and texturing (all important for high level vis) which is the main reason that Rhino will never be a visualization package (believe me I take no joy in saying that as Rhinos modelling tools are undoubtedly superior, and I hate working with ‘pivots’ in 3ds).
So while making shapes in Rhino is amazing, mapping/texturing a complex mesh (in a satisfying manner, with many UV channels) can border on impossible in many situations. I may be totally wrong, but this is the conclusion I have come to in my own work.
Now that being said if your models are intended to be sold to Rhino users that’s another thing, or if your models will not have the need for complex UV mapping also another. But in the End someone buying on Turbo Squid is likely going to expect a poly model with a decent quad flow that’s been properly UV mapped. Again while not impossible in Rhino I dont think it would be using the right tool for the right Job.
Id be curios to hear anyone else thoughts on this?
It would also be great if McNeal gave the visualization and meshing aspects of Rhino more attention, but then perhaps this is not really what rhino is built for.
Yeah, UVs were one of my main concerns, but as you say that depends on an object. Huge limitation for sure, but lots of stuff can be done with plain projections or naked shading.
My guess is an average TS buyer is mostly interested in a render-ready model (compatible file format, shaded etc)… like an out of the box item. So Im more worried about a file format that can bring in NURBS as NURBS in most packages AND at the same time retain shading. From my experiments, IGES does not carry materials, OBJ 3DS etc convert nurbs to polys. Maxs plugin powernurbs is great to bring in surfaces straight from rhino, but even if later saved in .max format its not readable by max without the plugin, thus not good for sales.
I was actually able to defeat Max on this front (that is to have a .max file with Nurbs geometry and shaders that is readable by any Max version), but no luck yet with maya…
I`m also not sure on render times and editability, also a consideration for potential buyers.
Maybe it wasn’t built for but there are a lot render engines implemented, a lot of user use it for viz work and there a some great non standard render features, so it’s time to forget the beginning of Rhino and to see Rhino as render platform too.
General STEP is a good universal NURBS format. Also FBX could be worth some tests.
For selling meshes … I would think about to use MoI3D for meshing. The meshes seems to be in a quite stable quality and low poly is good possible.
Render engines are great, but there`s also the usability factor - Vray for Rhino interface is nothing but pain.
I never played much with meshing, and I doubt any type of converting would yield acceptable topology… that is editable and clean, but still an option for sure.
The other way to capitalize on NURBS I`m seeing is selling the actual render rasters on shutterstock and such. Will try both ways.
We are planning to put a lot of work into Rhino texturing development during the 6.0 release cycle. It would be a huge help to us if you could explain some of those problems that you’ve been having with texturing so that we could see whether we can develop solutions for them.
I`m coming from Max so alot of this stuff should be familiar to max users, I think a number of certain really small things can be a great additions to Rhino aswell.
The major addition would be a universal nodal shading framework across all renderers (i.e. mat.editor, activeshade, renderview)
Isolate selected (thats not the same as select inverse and hide)
Fully custom keybinds (I tend to map most of the stuff I use and currently Im limited by predefined keys, i.e. no alt+XXX etc)
Xray selected (alt-x in max)
Align to…
Object/bounding box center as a snap
Enchaned gumball - ability to change/snap the gumball itself and use it as a pivot (for rotations/arrays etc)
Snaps… I bet most users are fine with them the way they are, but there`s a similar although slightly different implementation in XSI (softimage) which I loved - snaps are disabled by default and only became active after holding a key (alt in rhino). So its the inverse, you snap to the selected options only while needed (and of course can just toggle them on).
But like I said most of those are minor, and I enjoy Rhino the way it is
What does this do exactly? Have you tried v5’s Align command? It is a little different from V4. Or is ‘Align to’ something altogether different?
In V6, you’ll be able to create a custom CPlane from a gumball, so this may become at least easier, if not automatic. But, I think what you are saying is that any command asking for an origin of some kind like Rotate, Scale, etc should have a GumballOrigin command line option for this point, is that correct?
The way its implemented in Rhino5, Align command uses cplane as a reference for top/bottom/left/right, and thats fine in ortho views, but in perspective with default top cplane there`s no logic to it, imho.
Max uses world coordinates for alignment, thats the major difference I guess. Next one is - its using object boundaies, not exact points. So if you have a complex mesh youre not really sure where to snap to and you have to find workarounds, instead of just clicking “align bottom of this box to the top of that sphere”. I hope thats clear enough, Im horrible with making my point clear
As for the gumball, nah I was talking more about a visual way to operate things. Right now you`re able to rotate with gumball and it is set to an object center. So I mean the ability to move it off of there, snapping to somwhere else, for example to a point I need to rotate around. This can be implemented as a toggle for the gumball right mouse menu for example.
Hi Tool- I’m not sure if this is exactly what you want but check the RelocateGumball command (handy to have on a shortcut key or alias). Snap to any location + to reset the origin without reorienting the gumball, or set all three points to change orientation as well. Note custom gumball locations are saved in the file for top level objects but not for multiple selections or groups or control points. Also, if Ctrl is down when you start to manilpulate the gumball, it will only change the control itself, not the objects- that is a sort of shortcut for RelocateGumball.
As for texture development I guess Ill try to articulate some of the issues that are deal breakers for me without being a negative nancy. I love me some rhino, for shape making, but for Vis work I currently feel the need to both model and texture in 3ds.
Maybe the biggest, topological flow. If My NURB surface spits out a crazy triangulated mesh with a chaotic, unpredictable , or nonsensical arrangement then I have already hit the biggest burier to a usable UVW mapping workflow. In the absence of a logical mesh flow there is no way to move verts/sets of verts ( for UVW mapping purposes) to rectify mapping problems and warping. If the mesh doesn’t make sense (ie. pretty much quads that are organized according to the flow of the shape) then moving verts around cant really solve any problems. I don’t know if this is something that can even be addressed in a nurbs to mesh conversion. Essentially, when your seriously concerned about texturing the flow of the mesh is all important, and may even be a primary driver in the mesh flow decisions made during modelling. Currently in Rhino zero percent of this is addressed. I’m not faulting you guys for that, if I were an engineer it wouldn’t matter to me, my shapes would be precise and tolerances would be on. However for Vis, its a primary consideration.
Lack of tools (which in the face of mesh flow is really putting the chicken before the egg anyway). Pelt mapping, mesh relaxation ect., realtime coordination between Veiwport and texturing window selection and seams and vert changes. In complex UVW mapping these tools are essential.
For a good indication of what this all adds up to I would recomend watching this small 10 part series on UVW unwrapping in max. Perhaps your already aware of all this stuff. But, if your really looking into improving and expanding the texturing aspect of Rhino then this will give you a good idea of what tools and processes are essential to all that. Again not suggesting you need to replicate this work flow/interface/tool set, but the series (1 hour total) will really give you a very good idea of all that is involved (missing from Rhino) in more complex texturing.
Have to agree a node based system for shading and texturing would be a giant leap for those who use Vray with Rhino, giant. So many aspects of working with Vray and Rhino are just needlessly frustrating to the point of nearly unusable (especially if you know what the alternatives offer, and have the option).
This may be barking up the wrong tree, and perhaps the Vray guys are the ones to address these issues. drag and drop between map slots and other settings seems like a no-brainier. The need to see the texture of the mapping channel that you are currently trying to map is a necessity when using Vray ( this can currently be achieved through tedious workarounds that sometimes work, and many times bug out). Connection between environment settings and the view-port allowing you to see HDR mapping would be a big leap.
Okay, thanks for the opportunity to contribute my input. Again, not trying to be down on Rhino because what it does it does amazingly well for the most part (still got to get fillets 100% :P), and I really love it. But, these are the missing features which essential don’t really allow me to use it for the most part since for me Vis is the end goal, not mechanical. If these issues didn’t exist I would uninstall 3ds tomorrow and never look back.
okay thanks again, hope that is constructive feedback.
Yes - I see that. I think that will come - but you’re right, the crazy meshes probably need to be addressed first.
We could, of course, implement a node based shader system, but then every renderer would have to implement it. My guess is that it won’t happen. If you want a node editor for VRay, I think you’ll have to ask Chaosgroup. Other UI issues like drag and drop between map slots - again, you need Chaosgroup to do that - or get them to support the Rhino material editor (which does support that). Connection between HDR and viewport is also VRay - RhinoRenderer and Brazil both support that natively.
Some of those examples look promising, the remeshing of the letters at the bottom of the pager is a vast improvement for sure. At low resolution some of those would be okay for UVW, but the higher resolution examples still look intimidating, like the cone for example. But yes, certainly an improvement.
That’s what I figured. Wrong tree.
Thanks for looking at my feed back. Also, I think I forgot to include one major piece of feedback, maybe more of a wish list.
It would be great to just have a more usable mesh workflow in Rhino. Mesh tools are currently targeted almost exclusively at meshing and remeshing. Rhino could be an excellent mesh modelling environment as well given the power of the transform tools, but currently free form mesh modelling is just not viable given the lack of mesh specific tools and mesh modelling workflow implementation/considerations. Actually, many times I use tsplines just as a mesh modelling kind of plugin, and leave the smoothing off. Many of the Tsplines features allow for a usable mesh modelling workflow and I find that really valuable. These meshes are then perfect for going into any other application for subD or what have you. Maybe its just me and my workflow but that stuff is all very valuable, and allows me to stay in Rhino longer, where I prefer to model.
Youre totally right Andy, and thats why Ive suggested implementing a nodal framework, in a way that every 3rd party renderer has to use it. Its done like that in each major modelling app - a wide selection of renderers all using same core shading UI.
