Jewel posted:

Not sure why you're simultaneously trying to avoid state changes (usually done to avoid sending a lot of data to/from the gpu and keep things fast) while also trying to modify pixels on the cpu (which is the opposite, very incredibly slow and doesn't use the gpu's power at all). Might be an XY problem here. What are you attempting to do, and why can't you do it on the fast gpu instead of doing stuff on the slow cpu?

You should be streaming all your texture data needed up front to the gpu and just binding different textures back and forth with the draw calls, perhaps rendering to texture with rendertargets/framebuffers if you need feedback loops of some kind (like, say, a post process).

The closest thing you get to draw calls in different threads is building sub-command buffers asynchronously and combining them at some synchronous time in the future and submitting it to draw.

Interested to know what your exact goal is!

Joda posted:

I want to batch all meshes that use the same shader into the same draw call, and for that I need all textures to be in the same array texture (I'm doing it this way because I'm expecting to have a LOT of visually distinct smaller objects, and for that to be efficient I would have to batch them.) I don't want to modify anything CPU-side, but new textures will have to go through the CPU side from the HDD before it's on the GPU. I want to stream the data asynchronously, because I don't want to stall the application while I'm loading in a new texture.

I don't want different draw calls in different threads. All GL calls will be in a single thread. I just want to stream texture data into an array texture without stalling the application. This isn't a problem with something like the vertex data, because array buffers can be mapped directly to a pointer and double buffering those would max eat an extra MB or so.

Joda posted:

The standard models for GI papers tend to come from this website. At least the ones I've seen have almost all come from that list, with a few exceptions (like the AAO paper used some clockwork/gears scene that I haven't been able to find.) None of them fit your requirements exactly, but scenes like Crytek Sponza and San Miguel offer enough visual/geometric variety to demonstrate most concepts.

Hubis posted:

Can confirm. Crytek Sponza is good, San Miguel is great but it's a f'ing 1.8 GB OBJ file because it's plain text and all the instances are unrolled

I've been messing around with Blender trying to find a binary format that supports the required materials, etc. If my blender-fu improves I might even try to remake it with instancing, but my real job keeps getting in the way.

Colonel J posted:

Yeah, I used Crytek Sponza and haven't been getting very good results, and San Miguel is just too big for my limited RAM, when it's loaded in G3D with a tritree I just enter swap hell.

And thanks for this ^^ ! trying these out atm.

Hubis posted:

what problem are you having with Sponza? it *should* have good materials

Colonel J posted:

I'm trying to finally wrap up my Master's degree, and I'm looking for a scene to try out the technique I'm developing; surprisingly finding a good free scene on Google is a pretty awful process, and I'm not having much luck finding good stuff. I'm looking mainly for an interior type scene, such as an apartment, ideally with a couple rooms and textures / good color contrast between the different surfaces (I'm working on indirect illumination).

Ralith posted:

Can you share anything about your work? I've been reading about realtime GI lately and am quite interested in new developments.

Colonel J posted:

So yeah, not too groundbreaking work but I think I have enough meat for a thesis / good theoretical results but not a usable algorithm in practice. There's lots of things I could have done better in retrospect; for example a strategy of creating an extremely dense grid and removing nodes by keeping the error function as low as possible, creating some sort of octree, could have been a good solution. I don't think what I did is amazing , especially compared to the fancy stuff they're doing in modern games and cutting-edge research, but this was my first foray into CS (as a physics major) and lead to me working in the industry so it's not all bad

Xerophyte posted:

Hey, it sounds pretty good to me. I used to work in the same office as a team who worked on a lightmap and irradiance probe baker for games (Beast) and better automatic probe placement was always their holy grail. They had an intern who did what sounds like a very similar master's thesis to yours a couple of years back. I think he ended up using doing descent on the vertices of a 3D Delaunay tesselation, but light leaking was a constant problem. He had some heuristics for splitting tetrahedrons that crossed geometry and other boundaries but as I understood it things would get messy for any complex scenes. The thesis is here if curious.

Colonel J posted:

Hyvok posted:

How am I supposed to update my vertices with OpenGL? Everything works fine and dandy the first time I generate my vertices, but if I try to update them they just do not get updated. The only thing that seems to change is the size of the buffer. I've now spent a few hours going through most permutations of binding buffers and unbinding buffers and calling glVertexAttribPointer and glEnableVertexAttribArray and glDisableVertexAttribArray and seems nothing will make the vertices change in anything else than size.

My OpenGL thingie is very simple 2D thing, in init I basically create the VAO and VBO and vertex attribute pointers and then bind them and then create all the uniforms and shaders and what not. When updating vertices I call glBufferData (yes I know it reallocs and I should use glBufferSubData but right now I just want something to change on screen) and when drawing just glDrawArrays. This works fine the first time around, but second time around if I call glBufferData with new data (different vertices, different amount of them) only the number of vertices displayed on the screen changes but the vertices are not updated. I've tried unbinding the VBO before glBufferData and then binding it back, I've tried calling glVertexAttribPointer after glBufferData, tried disabling and enabling the vertexattribarray and tried practically every combination of these and it works exactly the same each time. What do I need to do to update the vertices?

At one point I was certain I figured it out since some place said buffers cannot be modified when they are bound (and they are bound all the time for me currently, because I just have one), but unbinding VBO and VAO, calling glBufferData and then rebinding makes no difference.

Xerophyte posted:

You could try a non-bitmap approach. The maximum quality solution is to render the TrueType splines directly but it's quite slow, challenging to handle filtering and aliasing, plus you have annoying corner cases for overlapping patches. I think at least some of our applications at Autodesk at least used to do fonts by switching between mipmapped bitmaps for small glyphs and tesselation for large glyphs; not really sure if that's still the case though.

Far as I know the current recommended approaches for both good quality and good performance are distance fields or median-of-3 distance fields, both of which effectively boil down to storing the glyphs as filterable, piecewise linear edge data in a low resolution texture. They can provide zoomable and alias-free text rendering at a single modest storage resolution. The drawback is that the fields can be somewhat tricky to generate, especially for the 3-channel median version. There are tools available to do the baking, I have no idea how easy they are to use.

Hyvok posted:

What is the best way to implement 2D text rendering? I've seen a few tutorials and stuff and the common approach seems to be to render the fonts to native size (with FreeType or something), then make a texture atlas out of them and push to GPU and just render them as textures.

Xerophyte posted:

You could try a non-bitmap approach. The maximum quality solution is to render the TrueType splines directly but it's quite slow, challenging to handle filtering and aliasing, plus you have annoying corner cases for overlapping patches. I think at least some of our applications at Autodesk at least used to do fonts by switching between mipmapped bitmaps for small glyphs and tesselation for large glyphs; not really sure if that's still the case though.

Far as I know the current recommended approaches for both good quality and good performance are distance fields or median-of-3 distance fields, both of which effectively boil down to storing the glyphs as filterable, piecewise linear edge data in a low resolution texture. They can provide zoomable and alias-free text rendering at a single modest storage resolution. The drawback is that the fields can be somewhat tricky to generate, especially for the 3-channel median version. There are tools available to do the baking, I have no idea how easy they are to use.

Ralith posted:

I wouldn't recommend distance fields for a dynamic application. They're usually computed by rasterizing your vector data at very high resolution and then running a somewhat expensive preprocessing pass on that output to compute a low-resolution distance field. They're also both slower to render (even ignoring preprocessing!) and lower-quality than a good GPU-accelerated rasterizer, which doesn't even require super recent gpu hardware.

I think for 2D CAD purposes where aesthetics aren't super important people often just approximate text outlines with a series of lines that you can handle the same as any other lines. Definitely don't try to store data for every possible zoom level; that will force you to use discrete zoom levels and require more space than just storing the high-resolution version and using hardware downsampling as necessary.

roomforthetuna posted:

Does nobody do it by transforming the Truetype data into a set of triangles to render? Seems like that would give you pretty good quality (not perfect splines but also not jagged, and you could set some "number of slices per curve" configurable values for how smooth you care for it to be), and reasonably cheap rendering since we can render a million billion triangles per frame these days and you most often wouldn't want any kind of exciting shader on there.

Ralith posted:

They're also both slower to render (even ignoring preprocessing!)...

Kanpachi posted:

Hyvok posted:

However I would like to support unicode

High Protein posted:

That's an interesting problem. Looking at your example picture, it seems that what you've effectively done is taking a point about halfway along an edge, and moved that along the edge normal a random amount (positive or negative). So you could keep doing that iteratively. However you'll have to make sure you don't end up with intersecting edges.
For the cracks you could do the same thing. The amount of iterations you use would decide how ragged the crack ends up being.

Hyvok posted:

Just rendering the text as a mesh might be an option as well, I just saw some site recommend against that due to the amount of vertices you will need to handle. Which did sound a bit odd since you can have A LOT of vertices nowadays...

Zerf posted:

Please elaborate on this. If we ignore preprocessing, rendering distance field fonts is just a plain texture lookup and some simple maths(which is essentially free because the texture lookup).

haveblue posted:

How much unicode do you want to support? The occasional accented character is probably easy enough but if you want to get really into the weeds with composed characters and bidirectional writing and such you might want to considering letting the OS text service handle the whole thing and make you one finished texture per label. Rolling your own unicode-aware layout is not something to be entered into lightly.

haveblue posted:

How much unicode do you want to support? The occasional accented character is probably easy enough but if you want to get really into the weeds with composed characters and bidirectional writing and such you might want to considering letting the OS text service handle the whole thing and make you one finished texture per label. Rolling your own unicode-aware layout is not something to be entered into lightly.

Ralith posted:

It surprised me too. I linked experimental data. There's discussion of implementation details as well.

Zerf posted:

I skimmed through the link, but where do you come to the conclusion that this is faster than distance field rendering? All the comparisons seems to be against CPU-based rasterizers, and the GPU part seems non-trivial to implement.

Xerophyte posted:

GLyphy is a GPU implementation that uses signed distance fields:


It surprises me, last I heard anyone say anything on the subject Loop-Blinn was considered complicated and (with filtering, at least) pretty slow.

quote:

The main difference between GLyphy and other SDF-based OpenGL renderers is that most other projects sample the SDF into a texture. This has all the usual problems that sampling has. Ie. it distorts the outline and is low quality.

GLyphy instead represents the SDF using actual vectors submitted to the GPU. This results in very high quality rendering, though at a much higher runtime cost.

Kanpachi posted:

Here I was hoping it would be a boring problem

I've implemented a 'roughing' algorithm like I've described for the edges in similar situations a few times before, so I'm not extremely worried about that, but I've never had to generate a triangulation for a concave shape with a bunch of vertices inside it. Can I just feed a list of vertices to a tessellation library, like a Delaunay triangulator or something, and get the results I'm looking for, or would I have to take additional care since I'm working with concave shapes?

This is what I'd like to do:


This is what I'd like to avoid:


Also, if anyone knows a good C++ triangulation library that can do what I want (or can speak to the quality of OpenSceneGraph's), I'd appreciate it. Sorry if some of these questions could be answered by my own experimentation, but I'm away from the office for a few days and would like to be able to turn over a few ideas in my head over the weekend and hit the ground running when I return to work.

Zerf posted:

Oh, I see, that's why. Thanks. On the other hand, here's an excerpt from the GLyphy Github repo:
So sure, if you are going to use SDF without computing it to a texture, it's going to be expensive. I still believe regular, texture-based SDF variants will be both simpler and faster than doing any other font rasterization on the GPU (but with the caveat that generating the texture is expensive and sampling artifacts can occur).

Kanpachi posted:

Kanpachi posted:

Back on this after a few days, but I've looked into GLUTess and it seems like I'm only able to specify the contour of the polygon. What I require is a near-uniform tessellation like the example I gave in my last post, since I need to be able to apply heightmaps. Possible with GLUTess or do I need something else?