Find below the latest Sneak Peek video, taking a little look at the progress of implementing the AssImp importer library, and the native loading of textured OBJ model in MAX:


I would have liked to show this importing a complex GLTF model with animation, but I ran out of time and decided to make the animation implementation a two-parter task. I had tinkered with the idea of showing you a character in a mutated spangled form, but perhaps it is best I present my best work to you during a future progress video.

cant wait fdor the second part and animated model importing

I can't wait to try out the new build!

Nice work Lee, looking so good already. Quick question: How is the terrain work going so far? Any news.

Terrain will work much like it does in Classic, you can sculpt and paint your landscape, on which your player can walk. For more details, we did a sneak peek and live broadcast on terrain which you can find on our YouTube channel: https://www.youtube.com/channel/UC1q1e3Q9IKMk4nDlAGb_5Jg

We will of course make the sculpting more capable, the texture painting nicer (for a given quantity of nice) and throw in some cool new technology such as virtual texturing for good detail over large terrain areas. You will also be able to expand the terrain as your game requires. Best to wait for a progress update on terrain which I am 'hoping' can be as soon as next week.

Hi Lee
Do I understand correctly that Asset Importer loads what you give it converting it to its internal format. Then you convert that format to the wicked Engine format.
If I am correct will the entity then be saved in the wicked compatible format avoiding having to be converted on each subsequent load/run.
Also if this is so will the Asset Importer be included in the runtime(standalone) version? If so why so?

Thanks
Rick

Ps I think you are doing an amazing job and much faster than I thought humanly possible .

If someone likes to dig into Sparse Virtual Texturing working with 32k textures.
and even, Sparse Shadow Maps

edit: fixing the link.

@Ratall : The plan is to convert the AssImp model format into DBO, and then DBO is stored for standalone executables. The DBO is then submitted to Wicked for rendering (after some internal hocus pocus). This ensures fewer dependencies for the standalone game and of course, faster loading of the model data as it's already in the format the engine uses. The speed of development is thanks to the team I surround myself with, I'm just the guy who takes all the credit

@3com : Great link, I have sent it to our terrain guy for a quick read. I am looking forward to seeing his progress, exciting times to see how performant the virtual texture approach will be. The technique allows for a very simple shader (which means faster shader), and yet retain the detail of the terrain on close inspection.

Glad to help.
Yes, it may be a good move and might help with the procedural terrain system, in the GGMax future development.

Edit: just adding some interesting info.



Other interisting one.

All information I need is what is the polygon and vertices limits ?

No idea on the final polygon counts, once we have functionality on the creation side we can adjust the density to ensure we get good performance on our minimum spec target GPU, but it should be a higher density than Classic, with no arbitrary limits this time. The idea of baking non-visual information into the Virtual Texture is one we have been considering, specifically the material type so we can trigger the correct footfall and impact sounds (i.e. walking on grass vs walking on rock, etc). Depends if it hits performance during the read, but I think it may be possible to intercept the data as it moves from the file system to the GPU texture.

@LeeBamber


If we cannot turn terrain off, can we at least retain the option to Hide Terrain and Water?

OldFlak....

+1 vote that there is a [0] Zero option on the choice for number of
terrain blocks?? Perhaps replaced by a grid?

Standart poly limit in other engines is about 65,000 per mesh

@ OldFlak



Dave

Nope, both unreal and unity is 100k with about 64k vertices, there abouts.Previously we used directx file format, which had hard coded limits, recently Lee upped the dbo limits as that is the native format that the engine used as it is a raw format which allows the engine to quickly load models. obj can easily do 250k polygons quite easily.Which is why I haven't used x format in ages for static meshes.

Not that I want to create a model with that high count, however with the new rendering engine and 64bit support, we could easily double or triple the polygon count.Because we lack basic geometry creation, especially with the new engine being able to render amazing indoor scenes.
Creating indoor environments like the cold war pack, which took advantage of the dbo file increased limits, the reasonable limit was about 27k per mesh before performance degraded, even at that count there needed to be some sacrifices with regards to level geometry detail.

The end result was generally that environments especially indoor ones were particularly ''clean''. Creating level geometry that is destroyed is seldom used as is costs quite a bit of polygons to effectively create the look needed.

The new engine is faster and should support quite a bit more detail, and would be a shame if it wasn't possible because of hard coded engine limits, as the new engine should be complimented with reasonable indoor level geometry without having to use several meshes layers to achieve the same thing increase the draw calls which is a bigger performance hit that having a single higher polygon mesh.

I could definitely achieve a bunch more with a little more headroom and reasonable leeway, which is why the question.

I recently made a model which could have looked awesome if there were more polygons to work with.I made the Hagia Sofia temple, which is an extremely complex model, just to make and design the mesh took well over 2 weeks, and then had to be reduced to nothing to accommodate the engine. Truly a shame, definitely want to do the model for max again.

Hence the question what will the limits be, we should have double polygon counts at least.

Polygonal limits, for the most part, will depend on the target platform (the target PC's CPU, RAM, and GPU). Unreal 5, which is won't be released for some time, can have millions and billions of polygons displayed on screen. But just because the engine can handle it does not mean that everyone's PC can. A polygonal budget is often determined (again, based on the target platform when released) only to help 3D developers create content. Thus, a game's design doc would set limits for individual items based on what they were (the weapon and hands models used in FPS, primary models, secondary models, etc.). Again, the limitation was not the engine, but the target platform.

So, technically, engines like Unreal and Unity don't have a hard polygonal limit per item or per scene. Export formats like OBJ and FBX do, though (250,000 triangles, if I recall correctly).

That is if you export from max for example, however zbrush will allow 2.2m easily.

AND those engines have basic geometry creation in the editor, which doesnt rely that heavily on meshes created externally.

The traditional method for this is to slice it into various pieces, which is due to PHYSICAL hard coded engine limits of the DBO format. Physical limits of gameguru is hard coded, and that is due to meshes being converted to DBO. Gameguru is able to handle far more polygons that this singular 81K polygons. It is able to handle 600K plus polygons without hassle.But due to engine limitations one has to slice the mesh in several pieces and make use of multi textured mesh, which drains GPU memory resources and adds draw calls, literally throwing performance down the drain.

Which is why I asked, what is the limits, sticking with the same ones, especially with lee showcasing high detail indoor environment won't cut it especially with the rendering engine and 64bit improvements. Which is why you have a building pack of almost just external buildings in the building pack DLC, adding in door areas, is simply some thing that the HARD coded DBO limit won't allow even if gameguru can handle more. We are talking about gameguru, talking about other platforms and game design documents ect, is irrelevant.Gameguru is PC platform, with known system requirements, requirements that is able to handle more especially in the event, with software like gameguru that doesn't allow creation of primitive geometry.

While the building editor might suffice for most people, there is more people that would like to do more and visually improve their scenes a little.







Gameguru Can easily handle 600K, in fact, it depends on the geometry and how it is placed, death valley example map, has 970K polygons with AI running around. Cold war does worse due to being an indoor environment and having to deal, with physics and collision, gameguru wasn't intended as a indoor game engine.

Yes, althought I was responding to you about GameGuru, but about Unity and Unreal, which does not have an internal polygonal limit for either scenes or individual meshes. You'd said:





Which has nothing to do with my post, which was responding to you about the limits you said that Unreal and Unity had.



In both Unity and Unreal, excluding add-ons that allow for some pretty awesome modeling, the basic geometry creation is primarily used for blocking in basic levels. This geometry is typically replaced by 3D models created externally.



Yet, you were the one that brought up both Unreal and Unity, to which I was replying.

@granada - yeah that was a thing but Lee said no plans for it now.


I did bring it up in that thread but got shot down for it.

Hence my present request

OldFlak....

He can’t go back on it now ,it’s in black and white (or should I say grey and white )

Dave

About poly count, It is for me a good that we must use wisely.
Sounds like car advertising to me.
Capable of achieving 200 km in just 3 seconds.
For what? At least here in Spain, there is no road, highway, or path that allows you to develop a speed greater than 120 km unless you want to go to jail.

What I'm trying to say is, how many models like the ship in the image can I put in a game, if I want it to be playable on a large number of platforms.
Even if Lee decides not to limit the number of polygons, the author of the game must do so, unless he decides to demand very high requirements.

Which is why a game developer sets their own polygonal budget based on the target platform. The game engine should not restrict you in this. So, if you, as the developer, want to target today's systems, you can do that. If you want to target systems that will be out in two years, you can do that, too. And if you want to develop for older PCs, you're free to do that. If the game engine restricts you now, then it is already, in a sense, outdated.