Using another rendering process?

[Super Suit 12]

I asked a while ago if blockland could update its rendering engine and have better graphics.
Other people said "All you'd get would be new functions" and that was about it.
What I'm talking about is that in Blockland, what other games now do fine (Dynamic point lights, directional light on all objects, buttloads of particles, lights and models) Blockland either struggles to do or fails to do entirely. This is an engine limitation but I don't understand how it can be a problem with Torque. If Torque is limiting the rendering, worst case scenario you put Torque in a terminal window (Dedicated servers already do this!) and simply have it pass rendering off to another process entirely by giving it all the data on everything.
Is this horribly difficult or impossible or what? This could really make the game look a lot nicer. Imagine waterFX making actual water-like ripples, chrome making things actually reflective like mirrors, etc.

Problems this could potentially be able to solve if you did it right, as well:
1. Unable to recolor things that aren't bricks, vehicles or players.
2. Limited number of accessories on the player.
3. No server-distributed GUIs.
4. Limited number of paint colors.
5. No custom FX like glow, chrome, undulo, water, etc.
6. Lack of dynamic point lights and the low light limit
7. Having a lot of certain types of model (items, for instance) making the game slow
8. Orthographic cameras are impossible.
9. Multiple cameras are impossible. (VR anyone?)

[Ad Bot]

[otto-san]

i mean it's probably possible with a DLL if someone really wanted to do it, and the game could definitely benefit from it in a lot of ways, but i'll address some of these issues you've listed

Problems this could potentially be able to solve if you did it right, as well:
1. Unable to recolor things that aren't bricks, vehicles or players.

this is a coded-in limitation of the spraycan (or more accurately, those are just the things the spraycan is designed to recolor), not an engine limitation. recoloring weapons and other datablocks on the fly is a bit trickier, but support for recoloring models on a per-datablock basis is 100% possible and very common

2. Limited number of accessories on the player.

this is also just a problem that exists because of how accessories work. they're baked into the player model itself and hidden/unhidden as needed. additional accessories are already added by mods like hatmod by mounting additional shapes to the player

3. No server-distributed GUIs.

this isn't so much a problem of it being impossible, it's just that you really can't do this without opening up massive security holes. GUIs and client mods are literally just code; if you allow servers to distribute that code to all players who join the server, any server host could automatically send and execute malicious code on clients. RTB had a very limited gui distribution architecture that wasn't widely used because it had to be highly limited by design to the point of being almost useless

4. Limited number of paint colors.

this is again just a product of how paint colors are networked; badspot put a hard cap on the number of paint colors because he wanted to limit network loads (even though it honestly probably wouldn't be an issue nowadays if the netcode could support it)

5. No custom FX like glow, chrome, undulo, water, etc.

this one could be potentially solved by doing this though

[Zeblote]

Is this horribly difficult

Yes. This would be a lot of hard work, and noone wants to do a lot of hard work for free to make badspot more money.

Not to mention that it would be easier to just dump bl entirely and start over.

[QuadStorm]

This would be awesome especially if it'd allow for some form of global illumination (VXGI?), but no one is going to bother doing this.

Anyways, you can use a small FOV to have more of an orthographic effect.

[Zeblote]

This would be awesome especially if it'd allow for some form of global illumination (VXGI?), but no one is going to bother doing this.

VXGI is incredibly expensive. You'd need a 1080 ti to get acceptable framerates at 1080p.

[Super Suit 12]

A few clarifications:
1. Unlimited non-vanilla accessories wouldn't be attached to the player object directly but rather just as a list of models and positions that match up with the player. I'm aware of how vanilla accessories work.
2. Servers use center/bottomprint as menus, I'm talking about something like that but with images rather than text for the GUI thing. Might actually already be possible. No code, all the logic is serverside and the client is just told the result.
3. Did I mention dynamic lighting?

[Shift Kitty]

Several of those don't have anything to do with the 'rendering process'.

[Conan]

i dont think you realize that everything you are suggesting here involves engine rewriting. dll's can only do so much - you still cant force clients to install a similar dll to allow them to see your changes to the game; if you could that would be essentially the same as allowing hosts to upload and execute files on the client which is literally the definition of a backdoor.

and the only thing that involves editing the rendering process that you suggested is dynamic lighting and orthographic cameras. multiple cameras are possible, but even with them VR would not be viable in BL for many other reasons.

[Zeblote]

You could totally make a new renderer and inject that as a dll. But it sounds like a pretty stupid idea.

[Super Suit 12]

you cant force clients to install a similar dll to allow them to see your changes to the game

You can require them to download and install it for themselves before joining, though, or simply not send them the excess data.
Yes, it does require some messing with stuff, but as long as a DLL can make the game run in a console while still having a client and send data to another process this is possible.
As for the accessories thing, I'm not sure why you can't just create objects that don't do anything, but simply contain data for accessories. The limit is that there's a limited amount of spaces to put accessories for the game to render them. If you're containing them somewhere else, as individual objects, and then rendering them with a different process that interprets them as player accessories, the server or client doesn't need to recognize them as accessories, just to pass them to the rendering process. Is there no way to store data and send it to the client like that?

[Conan]

You can require them to download and install it for themselves before joining, though, or simply not send them the excess data.
Yes, it does require some messing with stuff, but as long as a DLL can make the game run in a console while still having a client and send data to another process this is possible.
As for the accessories thing, I'm not sure why you can't just create objects that don't do anything, but simply contain data for accessories. The limit is that there's a limited amount of spaces to put accessories for the game to render them. If you're containing them somewhere else, as individual objects, and then rendering them with a different process that interprets them as player accessories, the server or client doesn't need to recognize them as accessories, just to pass them to the rendering process. Is there no way to store data and send it to the client like that?

requiring people to download and install dll's is bad form - if people cant be assed to install client mods, why would they install potentially much more harmful dlls (which is basically injecting or changing functions/code in the exe while its running and can potentially allow dll distributors to install viruses and such)? all these centerprint/chat/bottomprint/allow passing in guis changes can be done by requiring clients to dl a mod instead of using a dll.

i dont think you know how rendering or game objects work, given what you're saying here. we can already do this with hatmod quite easily - what's wrong with that system? what constitutes as "simply contains data for accessories"? "just pass them to the rendering process" doesnt make much sense either. Increasing the "limited amount of spaces" doesnt require changes to rendering engine - it can be done much more easily by revising the image mount system, or worked around using bots.

[Mr.Noßody]

we can already do this with hatmod quite easily - what's wrong with that system?

The only issue with hatmod and other addons that attach images to the player is that you can only have 2 or 3 added to a player before things like emotes and other avatar cosmetics begin to overwrite them.
This has something to do with how many 'slots' a player has. Apparently a standard blockhead has 2 or 3 free, (emotes using one of those when used).

I was experimenting with hat and chest items, and when holding a weapon and doing /alarm, my hat would go away.
This would make something like shoes (disregarding a good way to mount a model to each foot) a taxing use of these slots.

I believe that this is just a limitation of the blockhead minifig and has nothing to do with rendering.

[Conan]

The only issue with hatmod and other addons that attach images to the player is that you can only have 2 or 3 added to a player before things like emotes and other avatar cosmetics begin to overwrite them.
This has something to do with how many 'slots' a player has. Apparently a standard blockhead has 2 or 3 free, (emotes using one of those when used).

I was experimenting with hat and chest items, and when holding a weapon and doing /alarm, my hat would go away.
This would make something like shoes (disregarding a good way to mount a model to each foot) a taxing use of these slots.

I believe that this is just a limitation of the blockhead minifig and has nothing to do with rendering.

yeah, its not a rendering problem. if someone really wants to support lots of hats, you can mount bots to players to carry the items

[Mr.Noßody]

yeah, its not a rendering problem. if someone really wants to support lots of hats, you can mount bots to players to carry the items

Heheh, I wonder what the limits of that might be...