Bugs still in Neon


#1

For these bugs, I’m using the latest Neon, and the renderer is set to rhino.

Bump maps: I’m still having some real troubles with bump maps in Neon – I used to get some nice realistic mirrored effects with subtle bump maps and edge softening turned on. The bump maps look ok until I turn on edge softening, then everything goes all zig-zaggy. I’ve reported this in the past… I thought it was fixed at some point, but if it was, it’s back.

Turning bump maps on and off makes everything go all, well, neon colored. When I change a bump map or turn on on or off while neon is running, the object gets all trippy colored and I have to set the viewport to shaded then back to neon. While this is easy to work around, it does slow the process quite a bit, since starting neon over from scratch is much slower than updated a neon viewport.


(Brian James) #2

Thanks Heath, I’ve got this one filed as NE-436
(this report isn’t publicly visible yet but that’s planned)


#3

Thanks. The bump map issues are really a big problem for me now. Not sure what’s happening with this, as it worked fine, then broke, then was fixed I think, now it’s broke again. I rarely cry “urgent fix needed!”… But this is one of those times … as I’ve deeply incorporated neon into my presentation workflow, I’m trying to match some previous renders (with slight changes) and I cannot do that now…


(Brian James) #4

I understand Heath and hope we can fix this soon. @andy will know when this can get looked at. In the meantime, I found a workaround that might help. If you leave an image in the bump channel and just drop the influence value to 0% you’ll avoid the odd color shift. You can also swap bump images without the bug appearing and just raise the channel to 100% when needed. This will allow you to stay in Neon in front of the client.


#5

Thanks. The weird color issue you gave the workaround for is a mere annoyance… but it doesn’t matter as long as the other bug is there (the weird zig zagging of bump maps when edge softening is on) because I can’t use bump maps at all anyways. So, for me, dealing with that is the much larger priority. Thanks!


(Brian James) #6

Right, thanks for mentioning that again. I had forgotten about that part of this thread… maybe separate threads for each bug would be good.

Can you check something for me on any file that shows the zig zag with bump? Does the object have a custom UV map but work as expected with say a mapping primitive like box? I want to make sure this is already filed. Any screen shots or samples are good too when you have the time.


#7

Can’t do tests right now, but I do know that there was no custom mapping at all. Everything is just default settings on mapping.


(Brian James) #8

Okay thanks Heath, I’m not seeing the issue here with default surface mapping, a basic rmtl with bump and edge softening. Please send a sample file and tell me the render plugin if any you might be using when you can and I’ll file it.


#9

I’ll try to do that today. Thanks.


#10

Ok, here’s a simple example. Not the weird zig-zaggy stuff I was seeing in a much more complex file, but this shows something is going on. See the drastic difference in the reflections here?

Here’s the rhino file:
bump_test.3dm

Thanks…


#11

I can’t upload this model, but here’s a comparison of what I was getting before vs. what I’m getting now. The top was what I had (and want), the bottom is what I’m now getting (looks messed up). This is the exact same file (I didn’t match the view quite exactly, but it’s close):


(Brian James) #12

Thanks Heath. This is due to the render mesh on the model that is then used for edge softening. Check out the change if a custom render mesh is used. The ShowRenderMesh and HideRenderMesh commands can help to see what the custom render mesh tools are using.


I’m thinking the zig zag thing you mentioned might also be for the same reason. I’m betting the edge softening also blends the normals of the polys in the render mesh causing the stretch in the environment reflection with so few.

@andy, is this a bug or as designed?


#13

Nope… I’m not seeing that drastic of a change here. I tried showrendermesh and it showed the EXACT same mesh on this, so I used extractrendermesh and I’m showing that here. There’s no big change. And again, it didn’t used to do this.


#14

Here’s what I see in that simple cube file. Very different than what you are seeing?


(Brian James) #15

Okay got it, thanks for the images of the complex model that is now not rendering well. I’ll try and mock something up that shows that exactly.

Sorry I wasn’t more clear, I made a custom render mesh in the sample image above and although that might help in the complex example, I’d say it is a bug if the same render mesh calculated the reflections differently before.


#16

I see. Two things: 1) I hope to not bump up the mesh to more polygons than is absolutely needed, as I’m doing animations with thousands of frames, and every extra rendering second is a hit. And 2) I tried it, and though it improves, it still pales compared to before. It gets really weird around the edges, all zig-zaggy:

(PS: thanks for looking into this)


(Brian James) #17

I understand about the animation hit fully and I’ll do what I can to get this fixed for you. I’m having a hard time replicating the problem though for a bug report. If you can chop a piece of this out and embed all the textures so it’s the exact same file that would be great. You can send the piece to Tech@McNeel.com or to me directly brian.james@mcneel.com.


#18

I’ll email it right now. Let me know if that works for you… thanks!


#19

I take it all back… the problem has nothing to do with the bump mapping. It’s just the reflective surface goes all nuts around the edges when edge softening is on. It’s like the mesh triangles aren’t reflecting at the correct angle. That’s why you’re not seeing it with just a bump map.


#20

Here’s a pic. You can see the jaggedness is following the mesh. So… maybe I’m barking up the wrong tree. Is this a bug in edgesoftening after all? Like I said, there was a time when this wasn’t a problem, so it must be fix-able… hope this helps track it down. Thanks.