bwcc

Image2mesh was great too. It seemed like we were really close to getting a UB version. Not sure what happened. bw

EXR2mesh - does work well, although it has problems making smooth models when rendered to very high resolution. The nice thing about CyberMesh was the ability to make cylinders and spheres. And, the plug-in that EXR2mesh replaced (Image2Mesh) had another really nice feature. Black pixels in the mesh would make holes in the model. Still waiting on that. bw

That's what I was afraid of. I don't have much confidence that the NL plug-ins will get updated. PlacerDeposit hasn't changed since 2007. Is there any way that Camera could create the object if the Plug-in is still limited 2GB of memory? thanks, brian

I often run out of memory attempting to render an object created with PlacerDeposit. Will the new version of Camera address this? Is the limitation due to the 2GB limit on Camera v8? Is the plug-in memory the same memory the Camera uses? thanks, brian

Has anyone noticed a problem with EXR2Mesh? I can create a model. But, when I apply texture map to the model, the model renders but not the map. I can export the model as a fact, import and the map works fine. thanks, brian

I'm sure some are already aware of this, but the the next Mac OS (10.7) will no longer support PowerPC apps on intel Macs. So, that means no more Modeler and no more Transporter. bw

ditto...

how about a public beta? I know with other apps, this usually generates interest both with EIAS users and potential EIAS users. brian

I certainly understand why Triple D has to make this decision, with the user base of EIAS it has to be more work than it's worth. But, it's hard to figure out why the plug-ins and shaders have to die. Why can't EIAS take over support / ownership of the Triple D products? It seemed to work with Konkeptoine, the support has been better than ever since EIAS took over. I would think any scenario where users are using, buying and upgrading would better than just than just throwing them away. brian

have you tried it with obj files from Modo? Apparently, the obj files that Modo creates are quirky. Also, how does it handle morph targets? I use Modo to create a file with a vertex map for each morph target, usually works great. Currently, I save each morph target as an obj from Modo then convert each one to FACT in Transporter. I then import the original model then add the FACT files as targets. If Animator 9 converts the files on import will it do the same when creating a target? thanks - I would love to beta test it for you... brian

does this mean no more Transporter or a better Transporter? brian

Modo can export obj, then convert to FACT in Transporter bw

cool, thanks! brian

I have done that at least a dozen times, It has been the same problem since version 7 was released (I think 2007). The PPC version of Dante worked fine, once the UB version was released it stopped working. I started sending bug reports to EITG once version 7 was released. EITG could reproduce the bug and NL could reproduce the bug. They both told me at time that it was a problem in version 7 and it was fixed in version 8. I waited until 8 was released and it was not fixed, I would say that in EI8 Dante was even more unstable and it still would not work in Renderama. After EI8 I sent more bug reports to EI and NL. After the ownership change I was encouraged that there might be a chance of getting it fixed. I set up a file where the bug occurred and sent the bug report, everyone involved was able to reproduce the bug and nothing happened. The only solution I ever got was "don't use Renderama" which to me is not a solution. From what I can tell, the error occurs because of a problem within Dante. Every time I bring it up, the only response I get from EI is contact NL. I have contacted NL several times with the same problem and have never gotten any realistic solution. If you look through the bug reports on this forum I'm sure you can find the last one I sent. thanks, brian

It is disappointing and it has been disappointing for a long time. Dante is one of the best particle systems I have ever used in any application. Without it, EIAS is not nearly what it could be. When I bring up issues with any NL plug-in I get directed to NL. I think the people that ran NL have moved to other things. None of their plug-ins have been updated or fixed for at least 3-4 years. Dante, and a few other plug-ins, should really be part of EIAS. It could be still sold as part of a premium package but it needs to be owned and maintained by EIAS. Since EIAS has taken over Konkeptoine the support has been very good. I have had a few problems with Konkeptoine plug-ins recently and they were fixed quickly and worked perfectly. NL obviously has no intention of ever fixing, updating or improving any of their plug-ins. I own several NL plug-ins and would like to buy others, but I won't until I have at least some confidence of getting any level of support. EIAS has the incentive to fix the plug-ins and make sure they work. If NL can't support their plug-ins, EIAS and NL should be able to figure out some solution to keep them current and functional. NL plug-ins add so much functionality to EIAS, without them EIAS becomes a much smaller app. As EIAS tries to improve and become more modern, I hope they don't have to limit improvements to ensure that 5 year old plug-ins will still work. brian

UB Dante is really buggy, I used it a lot in EIAS 6 on a PPC without issue. Since version 7 and the UB version was released it has been unusable. Even when you get it to work it will corrupt projects to the point where they won't open until you remove the plugin from the Sockets folder and delete the object. It will crash EIAS consistently and constantly get memory errors. The worst part is that it won't work with Renderama at all. Try Power Particles Pro. It's has some limitations compared to Dante, but at least it works. brian

The reason I ask... I often have a situation where, as an example, I create a model with BlobMaker. I can set the EIAS resolution to 5 and the Camera resolution to 30. I get a quick easy to deal with model in EI and nice smooth high res model in Camera. But, once rendering the animation I notice that Camera takes significant amount of time creating the mesh for each frame. If the Blobmaker settings are not animated it shouldn't need to do this. It should be able to create the model once and use the same model file for each frame. So, As a work around I figure I can create the model in EI, export as a FACT and import so Camera will not recreate for each frame. I try to create the model in EI by setting the EI res to 30 and I get the memory error. It's not a problem specific to BlobMaker, The error occurs with any plug-in that generates geometry. The odd part is that even when I set the EI resolution to 30, I'm creating a model that is only 400,00 - 500,000 polygons. I know if I could create the model in EI, I could export/import and it would render quickly. I know EI can import models that are several million polygons. I am not trying to make a model that EIAS can't load. So the problem is maybe the plug-in memory or the the way the plug-in and EI share the memory. thanks brian

So, will EIAS 9 be 64bit or just Camera? Will EIAS 9 be able to use more memory? If the Plug-ins are ported to 64bit would it only be an advantage in Camera or also in EAIS 9? thanks, brian I'll assume that means no... bw

Just curious how EIAS 9 will be different with memory. I use EIAS 8 and often run into memory problems especially with plug-ins. Using Placer Deposit, Blobmaker and Mrs. Bebel I will get memory errors by trying to create a model that is too dense. I can usually render with higher settings than what can be created in EIAS. But even with Camera I will get memory errors. I think in EIAS 8 it is limited to 2GB of Memory, does the plug-in use it's own memory or does it take a piece of the 2GB? Is there anyway to get EIAS / plug-in to use more memory, even if it's slower? In EIAS 9, since Camera is 64bit, will that allow it to use more memory to create bigger models with plug-ins? or is that a function of the way the plug-in uses memory. Will EIAS 9 also be 64bit so it can use more than 2GB of memory to create / import more and bigger models? thanks brian

What about the Northern Lights Plug-ins? Will they still work? brian

well sorta... Tailor does work, most of the time. There is no preview in Animator and if you use for anything more than the simplest model it slows to a crawl. I recently did an animation and without TT the frames rendered in about 5-10 minutes, with TT render times went up to nearly 2 hours for some frames. You could also try Davinci's Chisel. It works in a completely different way, it creates a new model in Animator based on the source geometry. So you get a preview in Animator. It doesn't work on big models and is a little crash prone. I don't think the NL plug-ins are supported anymore so I wouldn't count on it getting fixed. But, when it works it's faster than TT. brian

Yeah, that's not what I'm talking about. I know you can use an alpha that is saved with an image, but I want to place a separate image that can be used as a mask for any other placed map. For example, an object might have maps placed for diffuse, specular, reflectivity and luminance. All the maps could be placed without masks. A separate image would be placed and designated as a mask. Then for each placed map, you could select the independently placed mask image to mask the map for each channel. This would allow you independently place the map and the mask and not have to go back to PhotoShop to constantly adjust the mask every time you adjust the placement of the maps. It would also be very cool if the mask could also be selected to work with shaders. brian

I have wished for this too. I'm not sure if it's possible, but it would be nice to be able to place a texture map to be used as a mask. It could then be selected as an alpha mask for any map in any channel. Being able to select it as mask for a procedural shader would even better. brian

I am having a problem with converting a model to FACT using Transporter. I have a model built in Modo, with 2 vertex maps. I can use these to create a model for EIAS with 2 morph targets. From within Modo, I freeze the model, then apply the appropriate vertex map, export the model as an obj. then convert it to a FACT in Transporter. When I use Transporter I always have to "Combine Duplicate Coordinates", "Combine Multiple Groups" and "Merge co-incident edges" This usually works well on creating models to use as Morph targets. it maintains the number and order of polygons and vertices. Sometimes though, I have to also check "Fix Smooth Shading" to get the model to shade correctly in EIAS. But, for some reason this will result in a different number of vertices for each morph target. If the number of vertices changes, the models don't morph correctly. Is there any reason why "Fix Smooth Shading" would change the number of vertices? The number of polygons remains consistent. thanks brian