easy rendering for Rhino in Windows
Any news on ETA for a long due update for nXt?
Is there something specific you're after?
We are working on a variety of projects for nXt including a more tightly integrated v5 product that will share more of the interface used by Brazil and the Rhino Renderer. That's underway but a certainly a few more months before we have prototypes to share. There is a bug fix service release due out before then although we haven't got a release date yet. I've also released a prototype of a stand-alone interface that can read .3dm files. I'm about to release an updated version that reads a bunch of Flamingo data from the .3dm as well.
Thanks for your reply.
I had some discussions with Scott Davison a while ago regarding problems with decal projections as well as the unification of mapping with Rhino 5 and nXt methods.
Most of the conversation was via email. Perhaps I should fwd you what we discussed.
Kind of in the same theme, I'm also having problems when redefining blocks which components have mapping coords. So say that I have an object with a planar texture on it and I make it a block. Then I want to edit this block with inplace block editor: The coords get shifted and the mapping widget jumps to a random (?) location either when I start the command or when I close it. Very frustrating. It hope that you guys do a good overhaul on nXt.Another problem is with artifacts created when mirroring a block that has textures.
I'll dig the emails with scott and send them to you
The decal thing probably isn't going to change-- that was done intentionally to prevent decals from "smearing along perpendicular sides" which was a complaint prior to nXt.
The "mapping unification" is part of the v5 rdk integration project which is still a few months away from a release candidate.
Don't know anything about the in-place block editor-- I'll get Scott to look into it.
I am looking into the mapping problem with the block editor and will get it fixed in the next Flamingo service release, there is a chance it is a problem with the block edit command so it may need to be fixed in a Rhino service release which I can also take care of.
You mentioned "Another problem is with artifacts created when mirroring a block that has textures" It would be helpful if you could send us a simple model that illustrates the problem so we can see if it is something we can fix in the next service release.
Thanks for your reply. Regarding the block editor problem, I think that the problem is that the mapping widget (and the actual mapping) are reset to 0,0 rather than the local coordinates of the block.
I'm sending you the original shots that I had sent to Scott on the mirrored block problem and also a sample model. Actually, the problem appears regardless of whether there is a texture or not. You will see that the sample model has a basic material. The side that has been mirrored it renders faceted.
I noticed also that if I explode the mirrored block, the command 'dir' show now the normals pointing inwards instead of outwards as when the block was defined. Shouldn't be kept inwards? Although changing the direction when defining the block doesn't seem to change the artifact problem ...
Thank you for you prompt attention to this matter.
It looks like there was a fix added to Flamingo to handle the mirrored block bug in Rhino that was then fixed in V5 so the Flamingo fix was basically undoing the Rhino fix. I cleaned up the code and it now only inverts the block mesh normal's when running in V4. This fix will be in the next service release I am currently working on.
Thanks John, I'm glad that you have it under control.
Since we are here ... is there a chance that relative paths will be supported for textures? It would be great to have something like ".\maps" so that they can be found under whatever folder the project 3dm file is located.
Currently I cannot enter such path in options:flamingo nxt search paths and I'm forced to only absolute paths. It would be very useful, really ...
Flamingo will automatically look in sub folders of the model folder when resolving texture file names so there should be no need to add anything to your path. By default Flamingo will look up to five levels bellow the model folder and return the the file name from the first folder it is found in.
On another note, I have looked into your BlockEdit problem and figured out how to fix it. There was a small problem with Flamingo not properly transforming the block mapping at render time which has been fixed and will be available in the next Flamingo service release. In addition there was a problem with the BlockEdit command not transforming object attribute user data, I was able to fix this problem and it will be available in the next Rhino service release.
Thanks John. You're da man !