macklebee

fair enough... yes its a strange one because I dont have the issue in the editor nor a standalone lua script that just loads a scene... but basically use the same code in bmax and it fails to work correctly. Confirmed by two others using their own code as well.

The API is not an issue for me (assuming this was also directed towards the problem I posted), but rather the fix for the saturation/contrast/brightness bug inside the water.frag file causes the top of a waterplane to render as solid grey in bmax. It is because inside the water.frag file there is no value for the contrast and saturation being set but yet you are using those to calculate the output color. If you need a simple bmax program just to load an editor scene with a waterplane object script, I can provide one. I just didn't think it was going to be necessary since it is easily replicated, but if you need one I will post it with the bug report.

the new water.frag file in 2.42 is causing the problem in bmax... not quite sure why it works in the editor/lua and not bmax though... it has to do with the uniforms contrast/saturation not being set to a value... if you set those to a float value of 1.0 then the shader allows the top surface of the waterplane to actually render... but then that screws up the so-called fix for the saturation/contrast/brightness bug for 2.42....

thats because Josh manually added your password back... the rest of us are waiting...

well there is something messed up with the water right now... Josh made changes to the water concerning: but I see absolutely no changes in the framework bmx files that I have for 2.41 and 2.42... maybe i dont have the latest files, but since my password doesn't work I cannot verify that... Did Josh forget to give us the latest framework files?

the commands for water in bmax do not appear to need 'fw.renderer' any more... just use 'SetWaterColor'... i am seeing something strange as well at the moment... I have a scene with water that was created with the editor that has the waterplane object inserted. It looks fine in the editor and also when I use a lua standalone script to load the scene... but whenever I load the same scene in a simple bmax program, the topside of the water is just grey... underneath the water looks fine... but the entire top surface is just a solid grey... do not really understand what the issue is at the moment...

rick, have you met mika?

well since LE3 will not have a realtime editor and it will lose a point for that and Max3D doesn't actually exist anymore, i think you already have an imaginary engine at 1st place...

no matter how many times i see that, it still always makes me laugh...

try this post in the tracker: http://leadwerks.com/werkspace/tracker/issue-75-setterrainheight/. it has some code examples to get you started.

yes. thats what you are doing with the editor as well.

you can fix it by either changing the model and adding thickness to the walls and beveling the corners or by changing the shadow distance/linear offset of your directional light.

looks great soamp! appreciate you showing all of the aspects of your game...

3) Ok so I can just export from UU3D as whatever then... MDL is apparently not needed. LE3 just automatically can use whatever format. Good to know. Which is not the case, i know, since you have repeatedly stated that MDL is the model format that LE3 is going to use. And you have suggested that if the model is in FBX/DAE then the editor is going to create the MDL model from it. My point is: Why should I have to export to FBX/DAE at all instead of just having the ability to export directly to MDL from UU3D. I am not the only one here that uses modeling apps that do not export to FBX/DAE. EDIT-- youve edited your post so my response to that is: Why do i need to have GMF at all? If the final format in LE3 is going to be MDL, why not just let me export directly to MDL from uu3d. The GMF format is useless to me other than to be used for the conversion to MDL. Its not like I can open up a GMF in other apps.

I am not talking about LE2. I am talking about LE3. And apparently you are not listening to the fact that people use UU3D for more than just model conversion...

So I have to get my current applications to support formats that you say are the industry standards for LE3, when right now they work perfectly for what I need in LE2? My current apps do OBJ/X/B3D. I use UU3D to convert to GMF. It works great. And unless you are going to make a direct converter for 3D World Studio, the same argument could be made there as well. Without being able to export to the final format from 3DWS, the export model is useless other than to be just auto converted to MDL.

like i have said before, you are assuming that everyone has modeling apps that export directly to collada or fbx... and that is simply not the case... i would have to use UU3D to convert to fbx... and thats just silly when the final format will be MDL.

Josh, it goes back to that conversation we were having concerning uu3d. People use uu3d for much more than just conversions. Also when it comes to LE3 and you expect people to just convert their models to fbx, the UU3D owners are going to want to convert directly to final MDL format. I have absolutely no use for fbx in my current pipeline. And the only reason I would need fbx is for the auto conversion to MDL with LE3. It would make more sense for us to not have to even use fbx at all and just export directly to MDL.

In my example, I only had one model loaded as well. There is nothing there but the model. If I move the camera to where I see one of the LOD's and then free the model, it is only releasing the current lod, the model reference, and any subsequent lods. The main mesh and any prior lod is not being removed.

:lol: some more of mika's ridiculous claims... sheesh...

you didn't have mipmaps in the first version; makedds has the default set to creating mipmaps.

Can we also request that people explain their reasoning; ie. experience with using their selected choice? I'd rather have an informed opinion based on someone actually implementing the physics engine in something other than just a demo of some boxes/drums falling or a bunch of people just voting because they are familiar with the name. EDIT: doesn't havok require you to purchase? EDIT2: I thought the goal for LE3 is to make it so the physics engine is a plugin feature so that any engine could be used? Or is this a poll for which one is going to be "officially" supported?

just use the bmax syntax and they should work

This issue really has nothing to do with garbage collection or setting something to null. From my test of MG's problem, there is an issue with freeing items from memory when there are LODs involved. If I load a model that has 6 LODs and free the model when i am looking at the main mesh, it will show in the log that the main mesh, the model reference, and all of the LOD meshes are being deleted. If I load a model that has 6 LODs and free the model when i am looking at LOD2, it will show in the log that only LOD2, the model reference, and LOD meshes 3 thru 6 are being deleted. But the main mesh and the LOD1 mesh are not. And I can verify that if i load the model again as it will only load the items that were deleted.

1) ~2MB/s 2) ~1MB/s 3) ~700kB/s location: Indiana