• Content count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About tiburbage

  • Rank

Profile Information

  • Gender
  • Location
    Redwood City, CA
  • Interests
    3D modeling, texturing, and animation, game development in Unreal 4, programming and writing, movies, games, guitar, music
  1. Thanks, Don. I'll make my way through some of these this week. Of course I'm also aware of some of the excellent feature-specific videos in the YouTube channel you and others have authored...
  2. On the UV mapping front: I recently used 3DC to UV unwrap some of the hard surface models I've been working on lately, and it reaffirmed what made me get 3DC in the first place. The default initial projection shell creation/packing was so good I didn't even have to manually define the shells (islands) It is so easy to obtain uniform parameterization, flattening with minimal distortion... All I ended up doing was a bit of unwrapping, flipping, etc. and it was deemed "good enough". And if I had been inclined to start from scratch in define my own UV shell borders, that's super easy to do. I could have gotten equivalent results using Maya's very good UV tool set, but it would have taken more time and effort. ZB has some nice artist-driven UV unwrapping functionality, but in my mind best suited to organic shapes, not hard surface... On the texture painting and map baking and export front, Substance Painter and Designer are probably better comparison candidates than ZB. I have both, and they are obviously powerful tools, but haven't yet had the bandwidth to become knowledgeable enough in either them or 3DC to have any opinion there. Hopefully, some useful, objective discussions will occur on that front.
  3. Good discussion, though with apps like ZBrush and 3DCoat these days, I think you really have to do the comparisons on a workflow-by-workflow basis. Texture painting, UV mapping, texture baking and map export, retopo whether artist driven or "procedural" (including ZRemesher and Decimation Master in ZB in that broad category), and finally, the complex topic of sculpting and model creation... I've invested hundreds of hours of learning time in ZBrush, but I came by here today because I still feel like the dream of being able to create complex models while mostly just thinking about SHAPE and not the arcane underlying details of their construction has still yet to be realized. As some have pointed out, ZB intends to make this so, but in my mind, the polygons are always there. So, at least at our current state of technology, voxels SEEM like the most promising way to create shapes in, at least initially, a topology-free way. So I'm hoping there is some good, up-to-date training material that can give me a good overview of model creation in 3DC. Of course, for both ZB and 3DC when approaching shape creation without thinking about topology, you do end up needing to think about creating a usable mesh in the end, so retopology toolsets follow closely behind...
  4. I'm using the Universal Manipulator in the UV Preview window in the UV room e.g. with an island selected, and had wanted to move a shell just in U or just in V, but can only seem to do "free form" moves. Tried just dragging on the horizontal or vertical lines of the gizmo, thought Ctrl or Shift might work as constraint modifiers, but so far no luck. Does the tool support 1D translates?
  5. Not a feature request per se. Just thought people might find these things interesting, and who knows there may be some ideas which would fit well in a 3DC context. Allegorithmic's Texture Painter, which implements what looks like a particle system approach to generating physics driven semi random texture effects... http://www.allegorithmic.com/products/substance-painter Quixel's dDo and nDo are really interesting tools dDo: http://quixel.se/ddo/ nDo: http://quixel.se/ndo/ These tools are basically Photoshop plugins so they can leverage the PS environment in general including layers etc, but also its selection and painting tools. nDo provides some really interesting normal map tools.
  6. I think most developers are taking a "wait and see" approach to GPGPU (general purpose GPU) aka CUDA and OpenCL. The main problems are: - there are only 2 GPU vendors and they are arch enemies with no motivation to cooperate on standards. NV is not interested in promoting OpenCL, while CUDA is NV-proprietary. - A lot of development effort has to be put into a multi-processing architecture, deciding what to do on the GPU vs CPU, how to coordinate those threads of execution. With CPU capability continuing to advance (more cores, higher clock speeds at reduced power usage), it is much more straight-forward to just take advantage of that well-known architecture. It is more straight-forward to simply work on making an app take advantage of multiple cores/threads. probiner, I'm going to be making a similar decision in the next weeks, but I personally am only considering NV cards. For one thing, I believe the NV OpenGL support is significantly better than AMD/ATI and pretty much has always been. AMD concentrates on DirectX. AbnRanger pointed out some of the current state of things in the NV Geforce lineup that makes a buying decision harder than it ought to be. I'm leaning toward this one currently due to the 4GB of VRAM, but haven't decided for sure: http://www.newegg.com/Product/Product.aspx?Item=N82E16814125462 GIGABYTE GV-N770OC-4GD GeForce GTX 770 4GB 256-bit GDDR5 PCI Express 3.0 HDCP Ready WindForce 3X 450W Video Card There are also 780's with 3GB for about the same price. I think the VRAM will be more important to me in the long run than CUDA cores... Sigh. More research...
  7. I wouldn't spend too much time reading C++ books... maybe look for some short tutorials on basic C++ syntax and usage. If you know Javascript at all, you'll already be part-way there. Based on a quick look at the AngelScript site, writing AngelScript code will look something like original C++, and unlike many scripting implementations is statically typed, but like other interpreted languages handles memory management for you (no raw pointers or heap allocation). The problem with Python is that it has a big footprint. I have heard of AngelScript being used in game engines before to provide their scriptability, and this is probably because of its familiar syntax, small footprint without external dependencies, and easy integration with app/libraries built in C/C++. If its primary purpose is to create macro-like automation within 3DC, it should do fine. Where Python really shines is where it is exposed as an external interface, letting TDs build glue/workflow applications in Python that drive e.g. Maya, Motion Builder, LightWave, etc. in production. With some apps such as Maya, you can effectively write plugins in Python as well. Neither of those may be 3DC objectives though.
  8. Just mentioning that the Textures > Texture UV Editor panel does have a "Normals" mode to display normals direction info. It would be nice in the "UV Preview" panel to be able to toggle between: Stretching hinting (what it has now), normal direction, and reveal overlapping UVs. Maybe the latter could be incorporated into the normals hinting.
  9. Well, the PNG specification does support stuff like indexed color if you wanted to do that. The important thing with what file formats one chooses is a combination of what characteristics your workflow requires (grayscale, RGB, RGBA, 8bpc, 16bpc, etc.) and what support the apps you use provide for I/O. It's kind of a "least common denominator" thing. I've never had any issues with .PNG in my workflows, which include PS, Maya, LW, 3DC, ZB. I can't vouch for import to Unity or UDK in terms of game engines...
  10. My use of 3D-Coat is currently pretty limited, so I can't comment about most of the issues you raise. I use LightWave Modeler for hard surface modeling, and its UV tools pretty much suck, so I use 3D-Coat for initial UV map generation/unwrapping, and Maya where good lower level UV tools are needed. Maya's hard surface model UV tools are pretty good, and organic/unwrap tools also decent, but 3DC's are faster in terms of getting the UV islands initially defined and uniformly parameterized. Anyway, I do have a few comments based own 20+ years now in software dev. johnnycore's list of stability or performance issues is so long that most developers I know, if confronted with it, would just let it "fall on the floor" (too much information). My thought on what work I would think it best for Andrew to work on in a drive up to release of v4, based on my own , are: * stability -- because there can still be things that are awkward, or features not yet there, or performance not being great in some areas, but if the user experience is frequently punctuated by crashes, most users will reluctantly move on. And a reputation for instability can ultimately sink an app and be hard to dispel once it gets that reputation. * UI freeze -- Adoption of a new app is so heavily dependent on user documentation and videos/tutorials. Even if there are some inconsistencies or rough patches in workflow, those videos especially can explain those things. However, both of these things can quickly become either confusing or invalid if the user interface keeps changing. Those quality and scope of those (YouTube) videos is, I think, critical to bring new users in. This also implies temporarily putting a moratorium on feature additions. * performance -- I would caution against significant architectural changes to try to achieve better performance this late in the v3 cycle. I think the key for driving toward the v4 release would be to try to identify the places where (inadequate) performance is going to have the greatest impact on the general professional user experience and which also would not require major re-writes (which WILL introduce additional bugs and probably new instabilities and lengthen the v3 dev cycle). The best time in a development cycle to do architectural changes is at the beginning of a product version cycle so the impact of these changes can have a long bake time (beta user testing). * Make sure those app-links are working with the current versions of the software they link with. I think it's great that folks outside of 3DC have contributed these, but they have to work well for the key link apps or 3DC will look bad regardless of who initially developed them. The hard work for those of you who do use 3DC and really push it to its limits is to try to help Andrew to focus on say the top 1-3 areas which are of greatest concern -- especially ones which you believe truly limit wider adoption of the app when these constrains become known. If 3DC v4 initial release is stable, well documented, and has adequate performance (on a hardware platform at least up to some well documented minimum standard) for the majority of users, it should be well received (and bring in needed new-customer-purchase revenue), and then the developers can have the breathing room to review their architectural decisions and begin the long process of redesign. Maybe even add staff!
  11. TGA is popular because it is apparently very easy to write an importer/exporter for, and at least in the past was kind of the common denominator for game engine usage. I pretty much always use PNG for non-HDR work because it is both lossless and has good compression, and supports 8bpc RGBA and 8 or 16bit grayscale.
  12. With "Preview Islands" enabled, 3DC will show the current island being hovered over in the model view in the preview window, but zoomed to fill the window. While I guess that is useful for giving a more detailed view of the island, I would find it more useful to have an option to have the island under the cursor highlight in the preview window but with the preview just showing the overall layout. I know you can when in "Islands" mode go in the opposite direction -- select the island in the preview window and see what gets highlighted on the model, but would still find the requested option useful.
  13. +1 I came here to log a couple of similar/related requests, which I post separately.
  14. In Maya, a Shape is equivalent to a LW Modeler layer. A Maya Shape, like a LW layer, can contain any number of unconnected meshes (shells). Maya doesn't distinguish between a "model" and a "scene" in its native .ma/.mb format. Maya does not have LWO I/O support, but does have .obj and .fbx import/export.
  15. Folks, While I was evaluating 3DC, I tried both OGL and DX 64-bit versions and didn't notice anything in particular. The DX version is said to be "faster". Does anyone have any comments about one vs. the other from the standpoint of: stability, performance, display quality? -Tom