[Thomas An.]

TRACKING STOPPED (Sep-12-2005) for Rhinoll v0.6.1
TRACKING STARTED (JUL-01-2005) for Rhinoll v0.6.1
_________________________________________

CRITICAL

• None

AVERAGE

• (A00.061.050701). Bad Sun behaviour. See topics in Maxwell Bug section link1, link2, link3 (Not sure if this is a Rhinoll or Maxwell problem)
• (A02.061.050703). Materials not saved reliably in the file, they are lost unpredictably after reopening the 3dm. It can happen with large scenes as well as small scenes. Sometimes merely working on an object (joining, trimming, exploding surfaces) will cause other objects to lose their materials. Other times when the materials are lost the render view still shows the textures although Rhinoll cannot retrieve the info.
• (A04.061.050701). Copying from one Rhino instance and pasting to another Rhino instance will cause the render options of the second to be lost and replaced with those of the first. It will also (occasionally) cause the lens length to jump to something unusual (eg from 50mm to 7mm).
  -UPDATE for A04.061.050701: The lens-length jumping is a Rhino bug, not Rhinoll. (See Newgroup link)
• (A06.061.050701). Assigning materials to block instances not supported.
• (A08.061.050701). Use of Match material is not supported.
• (A10.061.050701). The default film width and height (36mm, 24mm) will produce a render that is a mismatch with the Rhino Viewport. When the film width and height are 24mm, 24mm the result is correct.
  

INTERFACE ISSUES
Issues / problems relating to Rhinoll User Interface:

• (I00.061.050701). City names are not sorted alphabetically
• (I02.061.050701). The option 'Render only channels' should cause the option 'Open Maxwell display' to automatically clear (The same with 'write mxs only' )
• (I04.061.050701). When Rhinoll becomes the current renderer then the "Render" tab in Rhino options should be replaced with the Rhinoll "Maxwell" options tree. If this is not possible for some reason, then a suggestion is to clean out the options in that "Render" tab to avoid user confusion... or possibly migrate the Rhinoll "About" information to that tab.
  
• (I06.061.050701). Assigning the same bitmap to more than one object, the message "Maxwell warning: Bitmap Already Exists" shows in the Rhino command line after hitting render (actually it's buried in there during Assignation routine). It still renders fine and doesn't impact anything at all, it's just disconcerting to see error messages.
• (I08.061.050701). The longitude/latitude data are not in a D.d form.
  http://jwocky.gsfc.nasa.gov/teacher/latlonarchive.html

SOLVED
Issues solved from previous Rhinoll version:

• S01 (SOLVED). "Assignation of material" text is cluttering the command line buffer for large files with hundreds of materials
• S02 (SOLVED). The scene name is allowed to be left blank - As a result it creates filenames such as: ".mxs" and ".jpg" (".tga"). The user should be forced to enter a scene name.
• S03 (SOLVED). Bump coefficient of the materials should range from -999 to +999
• S04 (SOLVED). Reflection map is not working properly causing metals to render black. Plastics seem ok
• S05 (NO FAULT). Phantom materials remain in memory. After deleting an object the material is not dereferenced and the command line mentions "assignation of materials" for objects that are no longer there.

  If you create 3000 boxes and assing them materials, then remove the boxes, all the data of your old boxes remains in the scene due to the rhino undo mechanism; rhino needs all this data in order to be able to undo the last command. When you save the scene the "erased" materials aren't copied to the 3dm file. Rhinoll only use the not "erased" materials. (Pablo Gimenez, Jun/28/2005)

HISTORY
Links to previous bug reports

• Rhinoll beta 0.6.0 bug reports

[Axe]

I have a file with only 150 objects, and am losing materials every time I save/re-open the file. The majority are mapped with bitmaps (1 meg or less each and all jpegs). It doesn't seem to matter which materials are lost, sometimes jpegs, sometimes just straight diffuse colours. The odd thing is that if I set the viewport to "rendered display" the image maps still appear on the objects, despite the object properties indicating there are no maxwell materials applied.

When rendering, the objects with missing materials render grey.

Beta 1.2.2 Rhinoll 0.6.1

[Thomas An.]

I have a file with only 150 objects, and am losing materials every time I save/re-open the file. The majority are mapped with bitmaps (1 meg or less each and all jpegs). It doesn't seem to matter which materials are lost, sometimes jpegs, sometimes just straight diffuse colours. The odd thing is that if I set the viewport to "rendered display" the image maps still appear on the objects, despite the object properties indicating there are no maxwell materials applied.

When rendering, the objects with missing materials render grey.

Beta 1.2.2 Rhinoll 0.6.1

Yeah, I am beginning to lose materials in more situations as well. For example, simply working on a file doing Rhino stuff (like trimming, exploding, joining, etc... causes materials lost not only in the parts worked, but also in other objects that were left untouched)

[iker]

losing materials here as well

[Eric Lagman]

Same here still loosing materials. It will happen sometimes even without a save or closing rhino and reopening. Also I have been getting crashes when my render gets to a certain sample level. I cant tell what is causing these things to happen though.

[Thomas An.]

Hi everyone,

I know, I know this bug is not fun at all and it has been around for such a long time. It makes us Rhino people kinda loose some of the enthousiam in testing anything serious with Maxwell...

[Micha]

... I stoped testing maxwell up to a big bug fix and znouzas plugin is ready(I'm very disappointed to hear that Znouza get no response from NL).

But so I have time to improve some Rhinoman|AIR render technics.

[Micha]

... the old problem, I save a file and open it in second Rhino (I let the file open in a first Rhino task) - some materials are missing. But I find a solution: if I open the missing material befor I save the file, than the material are saved. The first aid way to save a file with all materials now.

[Micha]

... but 100% proof is this method not, so I start a small test rendering in a second Rhino task and check the materials befor I close a file.

[Micha]

... a cobalt metal is shown in the GL preview golden orange and in the layer manager it is orange too.

[MarkM]

In the output tab for screen name, if i check the box "Same as 3dm" it doesn't work, it still saves the file name as untiled.tga

Regards,
Mark

[Thomas An.]

In the output tab for screen name, if i check the box "Same as 3dm" it doesn't work, it still saves the file name as untiled.tga

Regards,
Mark

Mark,

Could you explain the steps on how to reproduce this ?
Thus, far I have not seen it happen on my end.

One thing to check is if your output directory is correct (I know this is kinda obvious... but sometimes its the simple things... )

[Thomas An.]

... a cobalt metal is shown in the GL preview golden orange and in the layer manager it is orange too.

Micha,

Thanks for the reports.

[MarkM]

Mark,

Could you explain the steps on how to reproduce this ?
Thus, far I have not seen it happen on my end.

One thing to check is if your output directory is correct (I know this is kinda obvious... but sometimes its the simple things... )

Thomas,
Just did a quick test. I open rhino saved the file as test.3dm in my C:/ dir and then went to the output tab and under file options for Project Directory I put in C:/ and for Scene Name I checked the box that says “same as 3DM”…… but Maxwell still saved it as Untitled.tga.

When you check the “same as 3DM” it grays out the infobox were you would write the name, but keeps the box name in their Untitled, would make since to me if when you select “same as 3DM” that it would change the name there as well.


Running
Maxwell 1_2_2a_beta
Rhinoll 0.6.1


Regards,
Mark

[johann.dugge]

Right Olivier, I was wondering about that also - I thought it may have something to do with the polygon cound of the emitter. Let's hope it's fixed in the new version (maybe accidentally, as they may not have known about this bug