Josh

What did you alter? Just the diffuse texture? Do you get a perfect match for all lighting environments? I think the specular component might be what is throwing the colors off in the first image.

For a computer that is "pretty beefy" that seems extremely slow. What graphics card do you have?

How long were you in for? If you use the near view distance setting, all these little objects will cost the renderer nothing when the camera is far enough away.

Is anyone having problems downloading the full 2.32 installer?

It happens to the best of us. I hope in the future we can get rid of external DLLs and make things simpler.

This function will handle the blending for you: Function BlendTerrainTexture2(terrain:TTerrain, x:Int, y:Int, h:Float[]) glBindTexture GL_TEXTURE_2D,terrain.alphatexture.reference._index glTexSubImage2D GL_TEXTURE_2D,0,y,x,1,1,GL_RGBA,GL_UNSIGNED_BYTE,[byte(h[0]*255),Byte(h[1]*255),Byte(h[2]*255),Byte(h[3]*255)] EndFunction The h parameter should be four floats like this: [0.0,1.0,0.0,1.0] ...or whatever values you want. The problem is this is a feature no one ever uses, so an error was overlooked and never addressed.

Alternating between turning and scaling the parent still produces sudden changes in the matrix. Try going back and forth between hitting the H and N keys. You may be on to a good idea here, but it's still not working perfectly right.

Your code produces errors, as well as shearing behavior. When I turn the parent, then scale it, then turn it again, the parent and child matrices change suddenly.

Screenshot, please.

Can you post the contents of your editor.log file?

Why wouldn't this work?

That's normal. You need to increase the directional light range because the mountains are cutting through the near frustum.

Quan, I ran your code with 2.32r4 and it worked perfectly. Perhaps you do not have the latest newton.dll in the same folder as your program. What is your graphics card? Does the editor.log file contain any information?

I was just uploading r4, try it now.

I adjusted the calculations to fix the parent rotation. When you have an asymmetric scaling of a parent, the child matrix can become sheared when rotated, and the engine calculations force nonsheared matrices to avoid degradation from floating point inaccuracy. So it may not be possible to an asymmetrically scaled parent's child to turn correctly, but I will continue to try to improve the behavior.

Please post your code. This was announced a few weeks ago. The serialization version is 220, the first integer of the file. Are you saying you had to do this recently, and now your files are not working? In the future, our own collision format will be implemented, since the Newton serialization thing is a pain whenever anything changes.

I don't think we'll need to go above 2.40, and that's with minor updates.

Not completely. Although he did point out the filter was being called on entities that weren't pickable, he just happened not to run into any problems with version 2.31, the way he was using it. A single mesh in the scene with no parent and the right collision type could have caused a crash in his program. It's a good idea to always check if a parent exists before using it. So there was some small error on both sides, and now it's fixed.

Glad to hear it.

Sorry to hear that.

I recommend Avast. It's free: http://files.avast.com/iavs5x/setup_av_free.exe

Yep. Find line 91 of road_node.lua. Change this: self.roadmesh:SetParent(self.model,0) To this: self.roadmesh:SetParent(self.model,1) Not enough information. I uploaded the missing sound files. What is your framerate when this happens? It could be a timing issue with the smoothing code used. This was recently fixed, but considering the size of your project, you might want to stick with version 2.31 for a few days while I get this ironed out.

All I did was modify the code that mixes it in, so it isn't as heavy and only appears in darker areas. I think I got a pretty good effect with the bloom shader. I wanted to drive up the blurriness of those caged light bulbs, but also get a good sky bloom when the HDR kicks in indoors. It's difficult because the bloom shader works on the whole screen (which we want, because that gives us that "magical" looking glow from objects in sunlight).

Version 2.32 is the biggest internal change in the engine in a long time. It's also the last time version 2.x will undergo this extensive of additions. LuaJit2 was implemented for fast Lua execution. This initially caused some BMX programs to not compile with the included modules. The rendering buffer storage scheme was modified somewhat in preparation for a new feature that is unannounced. Roads and saved to and loaded from SBX files, so they don't have to be generated at runtime. This caused some problems initially, too. A really efficient scene management system was implemented. This allows the engine to scale for very large games, especially when lots of small objects are off screen. It's a pretty advanced system, and there were initially some problems that had to be ironed out. A lot of this is stuff I want to have in version 3.0. I implemented it in 2.x because I figured it would be easier to first write in BlitzMax, and then translate to C++ later. This was probably the most difficult release we have done. One thing that magnifies those problems is the number of ways we have you can use the engine. Executing scripts from the editor, generating Lua glue code, etc. These aren't bad when everything is working, but it magnifies problems when they arise, because there is more that can go wrong. In version 3.0, we have a more uniform design centered around C++ and Lua. You can still use other languages, but I think the process will be a little simpler for us and for you. Having a stricter separation between "edit mode" and "game mode" in the editor will also help. Thanks to everyone who provided useful feedback this week, and happy coding.

Are you exporting an FBX file, or are you using the 3ds max GMF exporter? You'll get more help if you post the file in question. The 3ds max GMF exporter is a third-party tool. The FBX to GMF converter is the official modeling pipeline we provide.