When I look through the stock GG Classic assets, EVERYTHING
looks like post apocalyptic grunge. Nothing else, noda. Dark, grey,
dirty, smeared, grundgy, rusted and OLD. And this is no critique of the quality--
//whoever made them //. It's just an observation of the GENRE or type of assets
that come stock with GG Classic .

Also- many DLC's aren't much different, just a couple. I think I see a pattern
cropping up here-- or overgrown here!

Generally the type of content tgc, prefers they aren't a big fan of too clean assets.But that said adding variations of clean and different dirt maps and such costs some serious development resources and time, return on those aren't that great, which is why you need to strike a balance between what can be done for the average asking price of $29.99 a dlc.

With the increase price of max might also see a increase in price for assets and dlc, which might make it more worthwhile.
But as long as the pricing stays as it is, there needs to be a balance.I think it is unfair to expect unity or unreal assets on a gameguru budget, you get what you pay for.

TGC will definitely need to consider a pricing overhaul if they want to attract new talent and investment from artists outside of gameguru.
That said the old adage is applicable here, don't like it, there are dlcs, the store and 100's of other assets, or make them your self.
TGC has their own specific tastes and designs they want for their stock library, additionally the requirements for stock library is pretty strict so it imposes a little on asset freedom but not much, but assets in the stock library needs to be usable in every reasonable scenario, another reason why you might find a common theme in the stock library, the stock library is actually pretty awesome compared to other software.

Not sure what this has to do with the structure editor or ebe ?

"Not sure what this has to do with the structure editor or ebe ?"
Not much, just that the discussion is going that maybe we don't need any
EBE type tool-- just use what GG gives you, or what you can acquire elsewhere,
and place them with the built in editor. (I have no problem with this,
especially with copy and paste-- I hope it works as desired.)

Then- I just installed GGC on a newer computer, and am trying script testing--
Even with 10 DLC's added (but no Store items yet), I can't find much useful
items just to TEST my scripts let alone stick with them.

So, no it hasn't much to do with EBE unless it's removed and a new user wanted
only to just use the stock items! There's barely any good walls, floors or ceilings.
Quite limited doors. But this isn't my complaint, it's just the observation of the
overall 'grunge' look of TGC asset collection-- but there's a couple newer ones that
I really like.
I suggest a great, huge DLC with nice modern building segments--
and so much more! LOL

BTW, I got several of your store packs-- very good stuff, at great pricing!

"but assets in the stock library needs to be usable in every reasonable scenario,"
Well... I AGREE! But it's not being accomplished- according to this;

I only think (as a scripter) that there should be a rule that all objects sold on
the store must be modeled in the '0,0' > North coordinate at all times!
Please everyone, think of a new era where games are going to actually use
DYNAMIC, scripted objects!

To be honest, I think really nothing in the stock library is anything that people
would want to script to move around anyhow...

Look that is the issue with designing assets that needs to be used in every possible way, as well as easy to use, as well as multiple usage, especially if designing modular assets. You tend to lose the general flexibility and randomness you would normally expect to get.

Single use level entities for building levels, with the exception of foliage isn't common in gameguru nor would it be popular in the store if every one can only make the exact same level.Like I mentioned balance needs to be struck, that won't keep every one happy.
There was some talk on the store of providing such assets, that would be sold to one customer only, no one else would be able to buy it again, but that would entail a hefty price tag, and that is not really what the store is after.

So yeah if you want specific and highly personalized entities to build levels with, tailor made to your project, it isnt cheap, you are going to end up paying 100s.

This is simply how gameguru assets work

I'm planning on using a basic structure editor in my GG Max game so it'd be great if it stays! Even a basic one.

If the problem is that's it's 'basic', then embrace it. Call it the Basic Building Builder. BBB. Nobody can criticize it for being basic, cause that's the point. Then keep it and move programming elsewhere, develop other new things but there doesn't seem to be anything too wrong with a basic building editor like this.

IMHO, the EBE or structure editor - whatever you call it - should be a separate product/editor that exports to fbx or some other compatible format. My favorite way to make stores/buildings is using the S2 engine. They have a DLC that allows you to easily create buildings of almost any height using parametrics with no coding or design work and it then exports a building complete with PBR textures. If it did indoors as ell as outdoors it would be perfect.

GG Max needs a similar parametric editor that allows for externals and internals, but easy to use, create, texture and export. The S2 engine DLC should be a model for all to follow.

Mike

It already does that and saves as DB0 so being separate makes no difference really.
S2's DLC is pretty cool but its all American Buildings and you do see a pattern emerge after a while. Personally i just think what we have should be upgraded if anything but Lee has already said it stays as is for now.

Yeah, just leave what is there and for the time being leave it as it is.

Spend dev time making an engine we can use to make games - not yet another a model maker.
If you want to provide something more substantial, then make a DLC later down the track.

OldFlak....

That won't work, it needs to be integrated into max, meaning if they add a DLC just for that it would mean that they need a code basis just for those users.

So either every one gets it, or no one gets it, DLC is only useful for adding additional parts over and both the stock parts.

Not necessarily. Other software allows for the core program to be changed via addons, plugins, or DLCs in order to add functionality. I know one game engine being developed right now that is going to function that way. The core engine will be made available for free to end-users. If they need specific functions for their game (not models, but actual engine/editor functions), they can pay for the DLC and, thus, make their own version of the engine more powerful.

It wont work, unless you have actually used FPSC you wouldn't understand. Segments actually formed part of the core code, you aren't adding a shader or game logic, it forms part of the core code, collision detection, physics, rendering, shaders, lights ect. All needs to be told what to do.

Besides that FPSC nor gameguru or max for that matter will ever have a external add on, if you referring to the planned particle editor DLC, it is actually a program to create particles to use in max, and has nothing to do with max code other then rendering the particles. You can use any particle editor/creator that outputs what max would need without having to get the DLC. It isn't tied to the engine.

Segments will need to be integrated with the core of the engine like ebe is, it isn't some thing that can be added with a simple DLL, as you will still need to code the core of the engine that deals with physics and other aspects like EBE does, DLL simply isn't enough to handle that.

It simply isn't some thing that can be added as a DLC, due to the core of the programming having to be physically altered over and above a DLL add on you might as well just add to the core programming, besides that every DLL you end up adding is only going to slow the engine down some more while developing and playing a games.

You don't know how MAX is coded. Though you are probably correct for MAX, due to the team coding it, it's not something that is impossible for a game engine. Heck, other engines (Unity and Unreal) had addons that allow for similar functionality to be added. Unity even has a few full modeler that can be added to the engine, allowing the end-user to create, edit, and set up models for characters and level geometry (which includes collision, etc.). Therefore, it's very possible in other engines and, if so, could be possible in MAX ... provided they planned for such a thing. So, yes, it IS something that can work as a DLC for a game engine/editor. It just may not be something the team that codes MAX is capable of.

Yeah, DLC, Plugin, DLCP, whatever you want to call it.
Apparently Lee is a blackbelt coder - so anything is possible
Build the engine the way you want it to work - simples.

The real question is:
- do you want to spend valuable dev time on a feature that essentially means having just another modelling program built in
- or use the small teams resources in a way that maximizes Game Making tools within the engine

If you want the first option, then just leave what is already there in place and as-is. And come back in 5 years time when you have an engine that can be used to make games, and then rework the Modelling App in the engine.

OldFlak....

Heh. Have the engine without the EBE or structure editor in it. Then, a few years from now, release GameGuru MaxMAX, the max-iest Max yet, now with Structure Editor!

In any case, instead of any of us saying, 'Yes, he can!" and "No, he can't!" Why not just let us make suggestions and then let Lee and Co. tell us what they can and cannot do. If they say they cannot have the structure editor as a DLC (or whatever you want to call it), then fine.

Yeah, right.

Even the best black belts can be floored by a nicely timed right hook.

Mh... I don't know if Lee could go this way. But the idea from Argent_Arts is not bad, I think. Specially for performance.
Only a small core, wich is running fast with a new capseled process for DLC.

It is what many Software today is doing. Chrome for example... one process for every Browser tab but more interesting, for every plugin. That is the reason why the impact of chrome performance is not big, by using plugins.
I have installled 32 Plugins in Chrome. All is still fast like 0 plugins.

Even other software use modules... Photoshop, blender, Unity3D, most Coding-IDE's, even Games.

I think it is much to late, to change Max to a Modular System. But perhaps it woud be a great idea for what is comming after Max. It would be a new way. A flexible way. Perhaps the Tools some Coder here in the forums, can be integrated that way in GG - by users choice. Like Photoshop Filter and Plugins.

In my mind I see lot's of flexibility. And a way to make more money for TGC

Wait, what ? You must be joking. Google's chrome uses the most memory out of all recent browsers, no seriously since it has been around it hasn't used ram well at all. Google only started addressing ram usage issues this year, even MS with edge which is now based on chromium had to look at the browser again and shaved of only 27% of memory usage.

In fact adding extensions only increased memory usage even more. Chrome has been around since 2009, it only started looking at ram usage now. Where every one else was using and still using less processes for the same amount of work, chrome would use 13 processes to do the same work firefox, opera, safari, edge did in 3 processes. Average peak CPU usage is also higher as a direct result.

Have a memory leak and you pretty much down and out for the count.

Now onto photoshop, yes it makes use of plugins, but have you actually seen how much memory some of those plugins use, for example quixel suite





I really wish people would think before posting, and yes I am trying to say it in the least amount of condescending tone, however at a certain point you just give up.
Is it magically coded different to the other billions of programs, in particular 3D engines that it is physically impossible to address various problems it would face with regards to running separate processes. No not at all, max has common processes all other engines has, physics, rendering shaders, sounds, path finding, AI, collision, game logic. It isn't unique in any way, plus with having actual access to the wicked engine source code and documentation hosted on github. Makes short work of the guess work it entails.

Your biggest issue is, that max isn't an open ended engine, you would need to physically spend as much time on writing the plugin as you would almost rewriting the entire engine and editor to allow plugins, with the amount of coders TGC has simply isn't practical or a viable option. You would need to maintain both your plugin and engine/editor code base as the engine gets bug fixes and updates.

No, you wouldn't. It's simply geometry. The engine (Max, in this case) is already set up to handle collision on geometry, physics, etc. It's little different than importing your own models to use. Instead, it would be a system to place geometry, be it a plane or a "chunk" of geometry, to place simple (or even mesh) collision on it, and let the engine do what it already does. This is how most other 3D engines do their "magic" and other plugins/addons/DLCs take that into account.

Unreal and Unity aren't "open ended" engines, either. Yet developers have created addons/dlcs to add splines that create meshes in the editor (which also get the engine's collision and physics) to create unique shapes; full 3D modeling programs similar to stand-alone modeling programs, to create geometry that, yes, also uses the engine's collision system, physics, etc.; and a myriad of other addons/dlcs that add geometry or manipulate geometry on a variety of levels, all using the engines collision system, physics, etc. It's not impossible. It doesn't require an "open ended" engine. It is being done repeatedly in these engines. It could be in Max, too ... provided they code the editor/engine to allow for such things (even if it is only "open" to them, the developers).

EDIT - I forgot to mention the many addons/DLCs these other engines have to "snap" together levels using a grid system and pieces/parts. Even though they are different than EBE or the system that FPS Creator used, they function in a similar manner. TGC could create something similar (and, yes, do so without having to "physically spend as much time on writing the plugin as you would almost rewriting the entire engine and editor").

In any case, why not let Lee and company tell us what is possible or not for them to do with THEIR engine?

Sigh because it is entities, and the engine has been hard coded to deal with geometry, you don't seem to grasp the difference between a content DLC that doesn't modify the engine in any way, compared to a external program that injects it self into the core program to physically change the behavior and operation of the program by linking the program to some thing external in order to do so requires that the program it self allow it, oh wait that is definition of open ended, considering unreal engine code is open source, and unity allows custom packages but isnt open source, it was build from the ground up.

Since you are the expert, (being here for close to 15 years, and having used every single program since day one means absolutely nothing nor haven't learned any thing) on the subject matter explain exactly how you would implement max allowing adding and linking external functions.

Keeping in mind, that you would physically need to recode max and the max editor from the ground up to support such functions as by default it doesn't.

Explain how exactly the following aspects will need to change
Editor
Core engine
Physics
Sounds
Terrain
Collision
AI
Culling
Shaders

You have the working assumption that you can simply slap a DLL on and every thing will just work. Yes and while you are essentially going to paint geometry like with EBE you actually need to tell the engine what to do exactly with the newly imported geomerty and how it needs to render it over and above recoding the engine to support such additions.

What you are essentially left with is having to recode and having two sets of physics, sound, collision, shaders, rendering, culling ect. because if you don't you will need to psychically recode the core engine to actually deal with the addition of the external library as the engine still needs to know what to do with what you are adding regardless.

Now you could go create a branch off and have two separate sets of code one for the newly plugin and the stock engine, you have ONE coder and one or two people helping out.

It isn't practical it simply won't work like that, as it simply isn't viable, and TGC has never with regards to FPSC, X10, gameguru and max actively supported plugins and never will with max.

Instead of responding to you responding to me responding, I'll just re-post this part again:

In any case, why not let Lee and company tell us what is possible or not for them to do with THEIR engine?

You don't got my point. Not for Photoshop and not for chrome.

Of course all the plugins need memory and some consume so much that it crash. But, while my plugins hang or something, the core is mostly stable. Sometimes I have in chrome that a plugin is crashing. But at the same time I can continue browsing without restarting the browser. All are different processes. All together is much memory. But they are all processes of their own. It is equal how many plugins I install. While of course every plugin consumes memory, the core is staying fast.
At the moment I write this, I have 19 open tabs and 28 plugins. Thr CromeCore is only using 360MB memory (You can see it in chrome TaskManager with Shift+Escape).
Same at photoshop. Some filters use ectremly much memory and some hang up because of tthis. But the photoshop core itself, is only hangig from bugs adobe made in it.

I must admit, I'm not be able to explain it good in english. It is not my first language.
I just think that a system with plugins, add-ons, dlc, how ever you want to name it, is state of the programming art. Before I founded my own litte it company, I coded for some other firm. All had in common that their programs had something like a plugin system. Sometimes only a little thing, sometimes big and more deep. I saw the benefits. It's esear to change something without the need of programming in all areas. You can haandle different plugins with dedicated teams, the risk of makiing bugs in Area C while codinmg in Area F is much smaller.
Little Example: The EBE crashed sometimes at my PC. No big problem, I save many times. The promlam is, when EBE crashes, GameGuru is between crashing and hanging. I have to close it manually via TaskManager. Then stating it new... everything needs much time and would not be, if EBE where just a plugin wich crash.
Same with CharacterCreator or other things.

I'm just thinking... if the base is the same since 20 years or even more...does it make sense to hold on it the next ten years? I was suprised when they annonced to change the 3D engine. I was sure they will hold on their own engine. I was luckyly wrong. It was a good engine years ago. But when they go modern in this area... why not in other? The directX update, 64bit ... and so on. That they don't had a plugin system before, does not mean they will never have something like that.

Please note, I'm only thinking of how I (!) see it. Noone must agree with it. This are only my thouts why I would love to see something like this.

Actually I prefer you answer my question seeing as you vehemently defend a plugin route. I told you why it won't be possible what the actual work would entail and you made a counter argument, which probably based on never actually using segments ever. It is the reason why lee created this thread. Yes lee him self created this thread to debate what should be done with their engine.Go figure after all we the end users have to use it.

So if you going to ignore the question, I will rather ignore you in the process as well, as nothing productive will come from it, as you never actually once argued how it should and could be done, only referring to unity and unreal at one point which has nothing to do with max, and was wrong about that as well.



The base engine was never the same. FPSCreator is dark basic, X10 is a special Dx10 version of darkbasic, gameguru aka reloaded, was in part dark basic but an entirely new engine since darkbasic code has been entirely removed bar some legacy code and based on C#. Wicked engine is based on C++. This line of programs changed several times over the years, and nowhere near the same engine.

This line of software won't change, it has a specific market and audience in mind, and honestly people should really stop comparing it to unity and unreal as it has nothing to do with them and max isn't trying to be like them either. It will never compare to that, it was never intended to be compared like that either.

No, you'd just prefer to argue.

It's simple, actually. All the elements already basically exist in the editor already. You have snapping. You have physics. You have collision, etc. It all "works" already when you import an entity for use in your level. Instead of having EBE as it currently exists in both Classic and Max, or instead of having what they had in FPSCreator, you create a set of tools that SIMULATE how these work, but uses entities instead. In Max, due to The Wicked Engine, you can already change materials on an entity quite easily. You can manipulate entities (translation, rotation, and scale). You can snap them according to a grid, etc. These already make up the basics for something similar to EBE where you are placing wall, floor, and ceiling segments that snap together, that you can change the material for (the texture), and that work with the engine's collision and physics system.

With EBE, you "paint" out a bunch of segments for walls, floors, and ceilings by simply clicking and dragging. If you're creating walls, then you click+drag and walls appear, snapping together along the path until you release the mouse button. Before you click+drag, the end-user has to select what they want to "paint" - wall, floor, ceiling - and what the material should be - wood, paint, etc. Instead of having an EBE system, Max could base it off entities - both those that would come with the new Max "EBE-like system" and those imported by the end-user. The end-user would select from the entities available (wall segments, floor segments, ceiling, etc.), choose a material available for them, and then "paint" via click+drag, which would cause an entity to appear ... and another ... and another ... each snapping to the end of the previous one and continue to do so as long as the end-user keeps the mouse button depressed and drags.

Instead of having an actual EBE system, the DLC would be a simple TOOL that would emulate what EBE does, extending the way you work in Max. It would add the ability to not just drag in an entity from your entity list and force you to click, place, click, place, but to click+drag to paint out a complete row of the selected entity. It would come with a set of entities that you could use with it (floors, ceilings, and walls) that are set up to work perfectly with the tool. And it could also have a means to "group" what's made (even possibly restricting the size, similar to what EBE does currently) so the end-user could save the entire thing (all walls, floors, and ceilings) as "one" entity (or group ... or prefab) that can be moved and/or rotated into place. And if it's a group or a prefab, then the end-user could access the contents to further alter it (like you do in EBE).

Where you're thinking is limited is that you are insisting that EBE cannot be a DLC. But it doesn't have to actually be EBE at all. It could be a tool or system that SIMULATES all that EBE does. And by doing so, it would actually be much more powerful. From the end-user's perspective, it matters little if it's actually EBE or not. It only matters how it WORKS. If I am slinging out walls, floors, ceilings, etc. by click+drag; am able to select what I want to "paint" out; can choose the material they have; can have the entire thing as "one" prefab upon exit, etc., it matters little to the end-user whether it's actually EBE or a new system/tool that behaves exactly like it.

Now, let's go back to MY question:

Why not let Lee and company tell us what is possible or not for them to do with THEIR engine?

Yes, Lee did start this thread to get ideas from us. That does not mean we get to tell him what's impossible or not. It means we can put forth ideas (which is what he'd requested, right?). And he can look at those ideas and say, "Nope, we can't do that," or "Yep, that's a good one," or whatever. In other words, it's not YOUR place to say such-and-such is impossible. It is OUR place to be able to express ideas (including expressing the idea of having EBE be a DLC or not). Lee can look at the ideas we put forth and decide yay or nay or impossible for himself. Not you.

you do realise Unity is basically all plugins (or packages as they call it) right? and they can let you add or take out pretty much any part of the engine as you wish so saying it's not practical isn't true at all - if it's not the way TGC want to handle it then fine, that's up to them but they could do it if they wanted to.. just because someone doesn't agree with you doesn't mean you are right i'm afraid

Agree 100%

@ Lee, just in case you got waylaid with all the banter.

Why not just leave what is there and for the time being leave it as it is.

Spend dev time making an engine we can use to make games - not yet another a model maker.
If you want to provide something more substantial, then make a DLC later down the track.

OldFlak....

DLC's can (usually) be sub-contracted out- right?
In fact I think a Building Creator could/should be a completely separate program-
why not? I'm not expecting or suggesting Lee spend days and weeks looking for
programmers to sub contract out to. I think if it is made a DLC (I'm supportive
of that)-- then it can come AFTER GGM 1.0 is at least released.

If the tool exports to .FBX then TGC will have another income a$$et on their side.
Would it be just another SketchUp?! NO. They require a $ubscription now- Poo!
So make it even simpler and good value.

Here's some ideas Lee (when you get back to this topic) *After GGM release*
****** Ed. fixed for Direct interactive link.....***********
https://design.fbibuildings.com/
https://home.by.me/en/

Oh-- this 'DLC' if a separate program, could have SUB- DLC's
to expand the Building Creator with. I know you like that idea.
I was supportive of the Character Creator becoming a DLC
that was expandable...
Anyhow, my $ is waiting...

EBE is good as it is but it needs a good pack with shapes in the right size and some more roof styles in order to differentiate in my view.
Last year i've been busy with some roofs but have not released them yet.
That roof has a proper UV and is multitextured so the user can apply his own wall texture for the building he/she is creating.
I'll look if i can find the files and make a house with that roof as an example.
Shapes should be a good way to avoid a blocky structure.

To all a very good and healthy new year.

@Earthling45
"EBE is good as it is but it needs a good pack with shapes in the right size and some more roof styles in order to differentiate in my view."

Yes, they need more components, but from my experience EBE is quite slow and a
bit awkward-- no offense!! Did you look at the link above ;
https://design.fbibuildings.com/
?
That's a simple but amazing method for making buildings. I'm really impressed.
As many components as wanted could be added - of all various shapes and genres.
From Traditional homes to Warehouses to Medieval to Sci-Fi to Caves probably!

That certainly is a nice tool to create buildings.

But Lee deserves way more credit for EBE than he currently has gotten for it.
It can become slow when a structure becomes really complex but with a variaty of shapes it should be possible to create nice buildings without it becoming slow due to many created poligons and not be blocky.
Where it certainly should be improved is how textures are applied, do away with the atlas and make textures tileable on a wall or floor so that a 1024x1024 isn't stretched to 2540x2540 with high loss of detail as a result.

Below a little video of a some roofparts i've made in the beginning of this year.
Textures can be changed and applied through the FPE and are aligned with the walls of the EBE structure.
In this way it should be possible to make an entity pack for EBE where the enduser can create buildings in the style of his choice while the structure itself remains simple with few poligons.

I'm a bit late to the party here. I personally do not use EBE. I actually preferred the look of the original version, although many complained about it for some reason.
In general we are better off using models from other packages, but a white boxing type system would be very welcome. Basic primitives we can drop in, scale and rotate and drop textures on.

The surrounding walls and steps were all basic objects you can drop in and texture as you wish. Very useful, especially if you are fleshing a level out, but useable for some things in a game as well I would imagine.

Another image.
I won't say what engine I am using here, but I'm sure many can guess

Re-spawning this thread to open a suggestion in light of this notice from Lee;
"Yes, we will provide a way to save created grouped objects for use in any level."
Super!

So what if instead of two systems ( a group creator ), and an ( EBE )-- /I'm hearing some people
prefer to just use custom assets and don't even use EBE /
But it has come to my attention that aren't these two systems almost identical in nature? To save Lee and crew some work and design time, would it be possible now to just make a robust and terrific grouping system? (Maybe not really-- or maybe they have even started the design on these two systems?)

*** BTW- See my LAST statement; Yeah this was my thoughts, I thought it was an interesting idea- but maybe not so necessary (grouping is probably already mostly designed and implemented..... but read on if you want. ) ***

Sure, what I like about the current EBE, and what the EBE represents is built in textures that automatically produce walls and floor segments and a quick and easy auto- align feature-- and that's great and handy. Not saying to throw that out. In fact expand on it! I envision one process that includes both functions (the menu would show Grouping, and EBE as primary tasks.)

Here's what you would do; Create the EBE system, AND along the line, while you are constructing your building, or when that frame is complete, you could of course (I hope) go into the next phase (by menu selection) and enter that EBE structure into the grouping system to furnish that building with all your nicest decor ...save as a group. If it was one system, and it functioned as both needs smoothly and painlessly-- win.

To make this a simple summary-- just allow your EBE structure to become part of a group you can save-- or keep it separate as is... a group does not require an EBE and an EBE does not require a group- but they can be both.
Thoughts?

Yes the group system would work. That's why myself and several others have asked it to be made into a prefab type system at some point. Useful for many things.

I miss the multiple entity pasting, IIRC it was simply press I key adjust the size of the paint area and splat as many entities down as you want.

To me that could be extended, i.e. select the same function but now have editable values over on the right for it, so for example specify density of the splatting, minimum distance between already splatted entities (very useful for creating forests) maximum rotational values for each splat, i.e. so you can limit the splatting to only Y axis variation or +/- a certain amount for the 'tilt' angle. Maybe even specify a number of entities for a single splat which would be useful for example if you needed 2000 walls for a procedurally generated maze then you could simply drop one on the map, set it's parameters like script to use, then hit I key, select 2000 in the 'number of copies' box and left click over in an empty part of the map to generate them all.

@ AmenMoses-- ?!
What- it's gone?
If paint/ ker-splatting is gone... a bit pooo then. Why?
But exactly- it needed some extras for sure. Definitely bring it back.

It doesn't appear to be in the latest MAX alpha.

The I key still seems to work.

You had me worried for a second there!

Ahh, it's the radius marker thingy that's missing.

Also if you hold down the mouse button and drag it doesn't follow the mouse like it used to.

Ah yeah you have to sprinkle em now, which is probably a way to stop people going too mad on trees

I think adding vertex snapping and the ability to save and name groups of entities (prefabs/blueprints) would obsolete EBE

Might be true- and saving groups is a good plan. But the EBE enables the quick change out of textures-- texture one wall, swap the next as often as you like, on the go. This is one of the reasons that might still see an EBE as always beneficial. I could see a value in both systems, actually being integrated in some manner.

Hmm. I think the situation regarding the need of a new (and improved) structure-editor just got a lot better because of two things:

1.
the excellent new importers for 3D-formats!

2.
the availability of ASSET FORGE, which I just discovered via a news-alert by ITCH.IO. Looks neat! At least it makes construction and exportation of "cartoonish" 3D-assets a breeze... https://assetforge.io/

https://assetforge.io/

What do you think, peeps?

Yeah, not bad idea. Just need other genres above cartoony. (obviously now we getting into a hard to decide choice of what users want!) but I believe maybe you can switch textures or just colors inside this builder?

Won´t we be able to change the textures / colors of imported models right from within GameGuru Max? Correct me if I´m wrong, but I thought I have captured that in one of the three last videos by Lee...

Yes indeed

It is a nice idea.However there is an issue not sure how lee would implement it, as the engine stands right now, each mesh you add will add a draw call for the renderer and a drawcall for the shadows. The final entity will need to be rendered as a single entity mesh instead of the current method, it will destroy the frame rate pretty quickly.

If I remember FPSC classic was able to render many meshes as it used port culling, I asked lee if we would see the return of port culling and the answer was no.

You don't necessarily need a building editor for this type of thing you can do it right now, it simply requires exporting the meshes from the model editor at the specific coordinates it needs to be placed to assemble the building.

Would definitely be a nice addition to have something like this as i mentioned the engine isn't setup for grouping entities and rendering as a single mesh as this is really needed to avoid killing the frame.Whether it can be done or willing to do it I have zero idea. Lee has hinted a few weeks back about some thing with regards to the editor so remains to be seen what they will cook up

I am hoping it is some thing awesome, I have never used the current editor it was a bit primitive and lacking for my taste, but might be useful for someone else.

Sorry, mate. I lack modelling-capabilities, therefore I don´t fully grasp the meaning of your answer and especially the one above... What do you mean here with "model editor", GG does not have one.

I thought that with a tool like ASSET FORGE we could assemble whatever object we want in that exterior editor and them export it as one fabrication in order to finally reimport it as ONE properly parametrised single 3D-object with low polygony right into GG Max etc. - Similar to when we buy a prefabricated 3D-model at an asset-store and import it to GG Max?

I thought you meant that the building editor should be like asset forge or whatever. It depends what method the program uses for the final entity output.

For example you get grouped meshes and single mesh entities. A grouped entity for example is a group of meshes independent of one another exported as a entity. Both classic and max picks up on this and essentially each mesh in the group has a draw call. Which is costly to render if you have a lot of entities following the ''grouped'' entity method.

The other method is a single mesh entity with multiple materials, and associated texture UV maps. This method saves on the rendering calls, but uses a bit more memory due to the additional textures.

You can get away with this with using an atlas texture, with all the textures on a single texture for all the meshes as the atlas texture is only loaded into the memory once so you would save on the rendering calls for textures but you still have rendering calls for each entity.

So not sure which method your program uses, the preferred method is like the building editor a single mesh entity with one atlas texture and different UV coordinates.

However max has better multi texture support so you can have several smaller textures if needed, there will be some performance impact but to a far lesser extend then what was experienced in classic.

I said nice idea as you meant that the building editor should be more like the program you showed, it would be similar to that of the segment creator using prefabs to create your building or environment as here you aren't restricted by primitive mesh shape and it would allow complex mesh shapes and with the grid system it had as well as remembering the coordinates of entities you can construct a level in which ever program you use including 3D model editors and basically construct an entire level else where and only have to import the prefabs parts of the level.

It works well for the novice and experienced user alike. Sorry if I misunderstood you

What wizard of id means is if you export your objects with their pivot points offset according to the centre of the area/floor/scene they will load into GG (or any other engine) in the correct positions.

Here the basic floor is centre of the scene. Pivot is central by default.

Here the sphere has it's own central pivot so if loaded into GG will end up in the centre of the floor.

Here with the cube I have offset it's pivot point to centre of the floor. So if loaded into GG it will be in the exact same position as in Blender in relation to the floor object.
So it's fairly easy to make things as separate objects that can fit together using a grid system. Obviously only as part of a static scene. If you had physics on the object it would not like it at all, as it would be expecting the pivot to be central to the object itself and not offset to the floor. Similarly if you rotate an object that has been offset it will rotate around it's offset pivot and not at it's centre.
It's not quite as efficient as making it one model, but if you want different layouts in different rooms or to make an object you can piece together with different parts it can be useful. I used to do this (wow 20 years or so ago now) with DarkBasic, if designing any sort of static scene, thus saving having to set the position in code and hence make the process of laying out areas a lot faster.